Requerimiento para TEST3

Ingeniería de
Requerimientos de
Software
UNIDAD 3: Especificación requerimientos de

software (ERS)
TEMA 1: Documentación básica de requisitos
Ing. Jorge Vinueza Martínez, Mgs.

Perfiles públicos:
LinkendIn aquí.
Twitter: @jvinuezam1
jvinuezam@unemi.edu.ec
Orcid: aquí.
2
Twitter: @jvinuezam1 jvinuezam@unemi.edu.ec
Clase anterior…
RQ
Funcionales & Diseño de
No software
Funcionales
conclusión
desarrollo
feedback
objetivo
índice
inicio
Modelo del Arquitectura

Negocio de software
Alcance,
Documento
objetivos, Formal Prototipo
restricciones
(escrito)
3
TEMA 1: Documentación básica de
requisitos
conclusión
desarrollo
feedback
objetivo
 SUBTEMA 1: Estructura del ERS (introducción, objetivos, características,
índice
inicio
esquema, Perspectiva del producto)

 SUBTEMA 2: Audiencia (Características del usuario: perfil y jerarquía)
 SUBTEMA 3: Criterios y atributos de calidad (Restricciones)
 SUBTEMA 4: Estándar de escritura de requerimientos.
4
conclusión
desarrollo
Especificar la documentación básica de los
objetivo
feeback
índice
inicio
requerimientos de software concebidos en

las etapas de obtención de requisitos
5
Términos: “ERS”
Qué son las siglas ERS? Para que nos sirve el ERS?
conclusión
desarrollo
feedback
objetivo
índice
Este enfoque formal (ERS) es
inicio
Especificación de requerimiento de
software adecuado para sistemas
empresariales donde los
requerimientos son inestables. Sin
embargo, aún resulta útil escribir un
breve documento de apoyo que
defina los requerimientos de la
empresa y los requerimientos de
confiabilidad para el sistema…
Fuente: IEEE (2014). Guide to the Software Engineering body of

Knowledge 3.0, Pág. 6.
6
conclusión
feeback
Documento de
requerimiento de software (ERS)
desarrollo
inicio
índice
7
objetivo
Especificación de requerimiento de software
Algunas organizaciones grandes,

conclusión
desarrollo
como el Departamento de Defensa
objetivo
feeback
índice
inicio
estadounidense y el Institute of
Electrical and Electronic
Engineers (IEEE), definieron
estándares para los documentos
de requerimientos. Descarga formato aquí
Fuente: Página especificación estándar
8
La especificación de requisitos de software tiene muchos nombres en

varias organizaciones, aunque las organizaciones no usan estos términos
de la misma manera.
conclusión
desarrollo
objetivo
feeback
índice
inicio
A veces se denomina documento de requisitos empresariales (BRD),
especificación funcional, especificación de producto, especificación de
sistema o simplemente documento de requisitos. Debido a que
"especificación de requisitos de software" es un término estándar de la
industria, así lo llamaremos aquí (ISO / IEC / IEEE 2011).
9
Importante:
 Los requisitos entregables a menudo no pueden satisfacer las
necesidades de todos los públicos.
conclusión
desarrollo
 Algunas personas necesitan conocer solo los objetivos del negocio,
objetivo
feeback
índice
inicio
otras solo quieren una visión general de alto nivel, otras quieren ver
solo la perspectiva del usuario y otras necesitan todos los detalles.
 No espere que todos sus representantes de usuarios lean el SRS
detallado, y no espere que los desarrolladores aprendan todo lo que
necesitan de un conjunto de casos de uso o historias de usuarios.
10
conclusión
desarrollo
objetivo
feeback
índice
inicio
Audiencias del Documento de
11
Ejemplos: Usuarios de un documento RQ
Grupos de interés (Stakeholders)
Clientes
El departamento de marketing y
el personal de ventas necesitan Ingenieros de prueba
saber qué producto pueden
esperar recibir.
del sistema
Los probadores lo usan para
conclusión
desarrollar pruebas basadas en
desarrollo
objetivo
feeback
requisitos, planes de prueba y
índice
inicio
Administradores procedimientos de prueba….
Los gerentes de proyecto basan

sus estimaciones de Ingenieros
cronograma, esfuerzo y
recursos en los requisitos….
de mantenimiento
El personal de mantenimiento y
soporte lo utiliza para
comprender lo que se supone
Ingenieros del sistema que debe hacer cada parte del
producto…
Los equipos de desarrollo de
software necesitan saber qué
construir….
Fuente: Gerald Kotonya sobre ingeniería de requerimientos (Kotonya y Sommerville, 1998)
12
Redactores
Los redactores de
documentación basan los
manuales de usuario y las
pantallas de ayuda en el SRS y el
diseño de la interfaz de usuario.
conclusión
desarrollo
Personal de
objetivo
feeback
índice
inicio
capacitación Subcontratistas
utiliza el SRS y la documentación Los subcontratistas basan su
del usuario para desarrollar trabajo en, y pueden ser
materiales educativos… legalmente obligados a, los
requisitos especificados….
Personal Legal
se asegura de que los requisitos
cumplan con las leyes y
regulaciones aplicables…
13
Especificación de RQ
Para pensar…
conclusión
desarrollo
objetivo
Si una capacidad o calidad
feeback
índice
inicio
deseada no aparece en algún
lugar del acuerdo de requisitos,
nadie debería esperar que aparezca en el
producto.
14
Cuántas especificaciones?
La mayoría de los proyectos crearán solo una especificación de

requisitos de software. Sin embargo, esto no es práctico para
grandes proyectos.
Caso de estudio - ¿Cuánta especificación?

conclusión
desarrollo
objetivo
feeback
índice
inicio
Fuente: Software Requeriments, Third Edition, Microsoft (Karl Wiegers & Joy Beatyy, 2013)
15
Organizar y escribir el ERS
Sugerencias de legibilidad
Use una plantilla apropiada para organizar toda la información

necesaria.
conclusión
desarrollo
Etiquetas y secciones de estilo, subsecciones y requisitos
objetivo
feeback
índice
inicio
individuales consistentemente.
Utilice el énfasis visual (negrita, subrayado, cursiva, color y

fuentes) de manera consistente y juiciosa. Recuerde que el
resaltado de color puede no ser visible para las personas con
daltonismo o cuando se imprime en escala de grises.
Cree una tabla de contenido para ayudar a los lectores a

encontrar la información que necesitan.
Numere todas las figuras y tablas, deles títulos y refiérase a ellas

por número.
16
Si está almacenando requisitos en un documento, defina el

recurso de referencia cruzada de su procesador de textos en
lugar de números de página o sección codificados para referirse a
conclusión
desarrollo
otras ubicaciones dentro de un documento.
objetivo
feeback
índice
inicio
Si está utilizando documentos, defina hipervínculos para permitir
al lector saltar a secciones relacionadas en el SRS o en otros
archivos.
Si está almacenando requisitos en una herramienta, use enlaces
para permitir que el lector navegue a la información relacionada.
Incluya representaciones visuales de información cuando sea

posible para facilitar la comprensión.
Contrate a un editor experto para asegurarse de que el

documento sea coherente y utilice un vocabulario y un diseño
coherentes
17
Etiquetado de requisitos
Cada requisito necesita un identificador único y persistente.

permite referirse a requisitos específicos en una solicitud de
cambio, historial de modificaciones, referencias cruzadas o matriz
de trazabilidad de requisitos.
conclusión
desarrollo
Permite reutilizar los requisitos en múltiples proyectos.
objetivo
feeback
índice
inicio
Requisitos identificados de forma única facilitan la colaboración
entre los miembros del equipo cuando discuten los requisitos,
como en una reunión de revisión por pares.

Las listas simples numeradas o con viñetas no son adecuadas

para estos fines.
18
Secuencia de números
El enfoque más simple proporciona a cada requisito un número

de secuencia único, como UC-9 o FR-26
El prefijo indica el tipo de requisito, como FR para el requisito

funcional.
conclusión
desarrollo
objetivo
feeback
índice
inicio
Un número no se reutiliza si se elimina un requisito, por lo que
no tiene que preocuparse de que un lector confunda el FR-26
original con un nuevo FR-26.
Enfoque de numeración simple no proporciona ningún grupo

lógico o jerárquico de requisitos relacionados, el número no
implica ningún tipo de orden y las etiquetas.
Facilita la retención de un identificador único si mueve los

requisitos en un documento.
19
Numeración jerárquica
Si los requisitos funcionales aparecen en la sección 3.2 de su SRS,

todos tendrán etiquetas que comienzan con 3.2.
Más dígitos indican un requisito de nivel inferior más detallado,

por lo que sabe que 3.2.4.3 es un requisito secundario de 3.2.4
conclusión
desarrollo
objetivo
feeback
índice
inicio
Si inserta un nuevo requisito, los números de los siguientes

requisitos en esa sección se incrementarán.
Eliminar, insertar, fusionar o mover secciones enteras, y muchas

etiquetas cambian. Estos cambios interrumpen cualquier
referencia a esos requisitos en otras partes del sistema.
20
Etiquetas textuales jerárquicas
El consultor Tom Gilb (1988) sugiere un esquema de etiquetado
jerárquico basado en texto para etiquetar los requisitos
individuales.
Considere este requisito: "El sistema le pedirá al usuario que

conclusión
desarrollo
objetivo
feeback
confirme cualquier solicitud para imprimir más de 10 copias". Este
índice
inicio
requisito podría estar etiquetado como:
Print.ConfirmCopies.
Esto indica que es parte de la función de impresión y se relaciona con

el número de copias para imprimir.
21
conclusión
feeback Etiquetas textuales jerárquicas
desarrollo
inicio
índice
22
objetivo
Interfaces de usuario
La incorporación de diseños
de interfaz de usuario en el
SRS tiene ventajas y
desventajas. En el lado
conclusión
desarrollo
positivo, explorar posibles
objetivo
feeback
índice
inicio
interfaces de usuario con
prototipos en papel,
maquetas de trabajo,
estructuras alámbricas o
herramientas de simulación
hace que los requisitos sean
tangibles tanto para los
usuarios como para los
desarrolladores.
23
conclusión
desarrollo
feedback
objetivo
índice
inicio
Plantilla especificación de
24
Plantilla ERS
conclusión
desarrollo
objetivo
feeback
índice
inicio
Fuente: Estándar del IEEE para documentos de requerimientos (IEEE, 1998)
Fuente: Ver estructura estándar
25
Ejemplo ERS
conclusión
desarrollo
objetivo
feeback
índice
inicio
Fuente: Ver estructura ejemplo
26
El resultado del desarrollo de requisitos es un acuerdo documentado entre las partes
conclusión
desarrollo
feedback
interesadas sobre el producto a construir. Como viste en capítulos anteriores, el
objetivo
índice
inicio
documento de visión y alcance contiene los requisitos comerciales, y los requisitos
del usuario se pueden capturar en forma de casos de uso o historias de usuarios.
Los requisitos funcionales y no funcionales del producto a menudo se almacenan en
una especificación de requisitos de software, o SRS, que se entrega a aquellos que
deben diseñar, construir y verificar la solución. El registro de los requisitos de manera
organizada que las partes interesadas clave del proyecto pueden revisar ayuda a
garantizar que sepan lo que están aceptando.
(Karl Wiegers & Joy Beatyy, 2013)
27
Bibliografía Básica
1. PRESSMAN, ROGER S. (2010). INGENIERÍA DEL SOFTWARE. MEXICO: MCGRAW-HILL.

2. SOMMERVILLE, IAN. (2011). INGENIERÍA DE SOFTWARE. : PEARSON EDUCACIÓN DE
MÉXICO.
3. LARMAN, CRAIG.. (1999). UML Y PATRONES INTRODUCCIÓN AL ANÁLISIS Y DISEÑO
ORIENTADO A OBJETOS. NAUCALPAN DE JUÁREZ - MEXICO: PRENTICE HALL.
bibliografía
conclusión
desarrollo
feedback
objetivo
índice
inicio
Bibliografía Complementaria
4. VEGA, M. CASOS DE USO UML, UNIVERSIDAD DE GRANADA.

5. KARL W. & JOY B., (2013). SOFTWARE REQUERIMENTS, THIRD EDITION, MICROSOFT.
28
Ingeniería de
Requerimientos de
Software

software (ERS)
TEMA 2: Técnicas de especificación de

requerimientos de software

Perfiles públicos:
LinkendIn aquí.
Orcid: aquí.
2
Clase anterior…
RQ
No software
Funcionales
conclusión
desarrollo
feedback
objetivo
índice
inicio

Negocio de software
Alcance,
Documento
restricciones
(escrito)
3
TEMA 2: Técnica de especificación de
requisitos de software
conclusión
desarrollo
feedback
objetivo
 SUBTEMA 1: Documentación de requisitos impulsados por el plan.
índice
inicio
 SUBTEMA 2-3: Historias de usuarios.

 SUBTEMA 4: Especificación de comportamiento.
4
Especificar técnicas de especificación de
requerimientos de software concebidos en
conclusión
desarrollo
objetivo
feeback
las etapas obtención de requisitos mediante
índice
inicio
técnicas de análisis y negociación para

documentar las especificaciones de
requerimientos.
5
Términos: “DFD”
Qué son las siglas DFD? Para que nos sirve el DFD?
conclusión
desarrollo
feedback
objetivo
índice
Ilustra visualmente el límite de
inicio
Diagrama de flujo de datos, es una
herramienta para establecer alcance del sistema, identifica
claramente el alcance y límite entre el entidades externas (terminadores)
sistema que se está desarrollando lo fuera del sistema que interactúan
demás en el universo. con el de alguna manera…
Robertson y Robertson 1994
Fuente: Karl Wiegers & Joy Beatyy, 2013
6
conclusión
desarrollo
objetivo
feeback
índice
inicio
Técnica de especificación de
requerimiento de software
7
Diagrama de Contexto (DFD)
Diagrama de contexto?
El "sistema" dentro del

círculo podría abarcar
cualquier combinación de
conclusión
desarrollo
software, hardware y
objetivo
feeback
índice
inicio
componentes humanos.
Las entidades externas en los
rectángulos pueden
representar clases de
usuarios (Chemist, Buyer),
organizaciones (Health and
Safety Department), otros
sistemas (Training Database)
o dispositivos de hardware
(Bar Code Reader).
Figura 5-6: Diagrama contextual parcial del Sistema de seguimiento de

productos químicos, pág. 93.
Fuente: KARL WIEGERS & JOY BEATYY (2013). SOFTWARE REQUERIMENTS
(Third Edition). Microsfot Corporation.
8
Mapa de ecosistema
Mapa ecosistema?
Un mapa de ecosistemas
muestra todos los sistemas
relacionados con el sistema
conclusión
desarrollo
de interés que interactúan
objetivo
feeback
índice
inicio
entre sí y la naturaleza de
esas interacciones (Beatty y
Chen 2012).
Un mapa de ecosistema
representa el alcance al
mostrar todos los sistemas
que se interconectan y que,
por lo tanto, es posible que
deban modificarse para
adaptarse a su nuevo
sistema.
Figura 5-6: Mapa de ecosistema parcial del Sistema de seguimiento de
9
Árbol de características
Un árbol de características
es una descripción visual de
las características del
producto organizadas en
conclusión
grupos lógicos,
desarrollo
objetivo
feeback
subdividiendo
índice
inicio
jerárquicamente cada
característica en niveles
adicionales de detalle
(Beatty y Chen 2012).
El árbol de características
proporciona una vista
concisa de todas las
características planificadas
para un proyecto, lo que lo
convierte en un modelo ideal
Figura 5-8: Árbol de características parcial del Sistema de seguimiento de para mostrar a los ejecutivos
productos químicos, pág. 95. que desean echar un vistazo
Fuente: KARL WIEGERS & JOY BEATYY (2013). SOFTWARE REQUERIMENTS rápido al alcance del
(Third Edition). Microsfot Corporation. proyecto.
10
Lista de eventos
Una lista de eventos

identifica eventos externos
que podrían desencadenar
conclusión
un comportamiento en el
desarrollo
objetivo
feeback
sistema. La lista de eventos
índice
inicio
describe el límite del alcance
del sistema al nombrar
posibles eventos comerciales
activados por los usuarios,
eventos activados por el
tiempo (temporales) o
eventos de señal recibidos de
componentes externos,
Figura 5-9: Lista de eventos parcial del Sistema de seguimiento de como dispositivos de
productos químicos, pág. 96. hardware.
11
Resumen
Observe cómo la lista de eventos complementa el diagrama de contexto y el mapa del ecosistema. El
diagrama de contexto y el mapa del ecosistema describen colectivamente los actores y sistemas
externos involucrados, mientras que la lista de eventos identifica lo que esos actores y sistemas
podrían hacer para desencadenar el comportamiento en el sistema que se especifica. Puede comparar
la lista de eventos con el diagrama de contexto y el mapa del ecosistema para verificar que sea correcta
y esté completa, de la siguiente manera:
conclusión
desarrollo
objetivo
feeback
índice
■■ Considere si cada entidad externa en el diagrama de contexto es la fuente de algún evento:
inicio
"¿Alguna acción de los químicos desencadena un comportamiento en el sistema de seguimiento
químico?"
■■ Considere si algún sistema en el mapa del ecosistema conduce a eventos para su sistema.
■■ Para cada evento, considere si tiene entidades externas correspondientes en el diagrama de
contexto o sistemas en el mapa del ecosistema: "Si se puede recibir un contenedor químico de un
proveedor, ¿aparece el proveedor en el diagrama de contexto y / o mapa del ecosistema?“
Si encuentra una desconexión, considere si al modelo le falta un elemento. En este caso, el proveedor no
apareció en el diagrama de contexto porque el sistema de seguimiento de productos químicos no
interactúa directamente con los proveedores. Sin embargo, Vendor está incluido en el mapa del
ecosistema.
12
conclusión
feeback
Diagrama de Flujo de Datos (DFD)
desarrollo
inicio
índice
13
objetivo
Diagrama de Flujo de Datos (DFD)
Qué son las siglas DFD?

conclusión
desarrollo
objetivo
feeback
índice
inicio
Es una técnica de modelización, que
nos muestra un sistema como una red
de procesos conectados entre ellos
por flujos y almacenamiento de
datos.
Nota: Los diagramas de flujo de datos fueron propuestos por Larry Constantine, el
desarrollador original del diseño estructurado, basado en el modelo de computación
de Martin y Estrin: "flujo gráfico de datos".
14
DFD: Conceptualización
En síntesis, el diagrama de flujo de datos describe:
Los lugares de origen y destino de los datos (límites

conclusión
desarrollo
objetivo
feeback
índice
inicio
del sistema).
Las transformaciones a las que son sometidos los
datos (procesos internos).
Los lugares en los que se almacenan los datos dentro
del sistema (repositorios de datos, base de datos); y,
Los canales (flujos) por donde circulan los datos.
15
DFD: Componentes
1. Proceso
conclusión
desarrollo
objetivo
feeback
índice
inicio
2. Flujo
3. Almacén
4. Terminador
16
DFD: Características
Existen datos de entrada.

Existen productos/salidas.
Entidades que proporcionan entradas o que reciben salidas.
conclusión
desarrollo
objetivo
feeback
índice
inicio
Existen procesos que transforman entradas.
17
DFD: Proceso
Son funciones o procedimientos que transforman entradas de

datos en salidas de información. Su nombre deberá ponerse
mediante una frase imperativa, que consistirá idealmente de un
verbo activo seguido por una cláusula objeto, cuanto más simple
conclusión
desarrollo
objetivo
feeback
mejor. El proceso se representa gráficamente como un círculo o
índice
inicio
rectángulo de proceso (Ver ilustración). Los sinónimos comunes
son burbuja, función o transformación.
18
DFD: Flujo de datos
Representa un transporte de paquetes de datos desde su origen

hasta su destino, es decir que representa una estructura de datos
en movimiento de una parte del sistema a otro. Puede imaginarse
como una tubería por donde se envían paquetes de datos, pero
conclusión
desarrollo
objetivo
feeback
deberá tener una descripción de su contenido la cual deberá
índice
inicio
elegirse de forma que sea lo más útil posible a los usuarios que
revisen el DFD. Se representa gráficamente por medio de una
flecha que entra o sale de un proceso. El sentido de la flecha indica
la dirección del flujo.
19
DFD: Almacén
Representa un archivo lógico en donde se agregan o de donde se

extraen datos. Es una estructura de datos, pero estática. Puede ser
físicamente un archivo de tarjetas, una microficha, archivos de
papel, o un archivo en cinta u otros dispositivos de
conclusión
desarrollo
objetivo
feeback
almacenamiento. Deberá elegirse el nombre que sea más
índice
inicio
descriptivo para el usuario, que identifique los paquetes de datos
que contiene. Implica escritura, actualización o borrado de datos.
Implica lectura o recuperación de información almacenada.
20
DFD: Terminador
Representan fuentes (origen) o destinos externos de datos que

pueden ser personas, programas, organizaciones u otras entidades
que interactúan con el sistema pero se encuentran fuera de su
frontera. Cuando el sistema que está bajo análisis acepta datos de
conclusión
desarrollo
objetivo
feeback
otro sistema o bien se los provee, este otro sistema es un
índice
inicio
terminador. El analista no puede cambiar ni los contenidos ni la
forma de trabajo de un terminador. El terminador se representa
gráficamente como un rectángulo.
21
Niveles DFD
Los diagramas derivados de los procesos principales se clasifican en

niveles, los cuales son:
Nivel 0: Diagrama de contexto.

conclusión
desarrollo
objetivo
feeback
Nivel 1: Diagrama de nivel superior.
índice
inicio
Nivel 2: Diagrama de detalle o expansión.
22
Niveles de DFD: Características
Nivel 0: Diagrama de contexto: En el diagrama de contexto solo se

dibuja el proceso principal y los flujos entre este y sus entidades
externas.
Nivel 1: Diagrama de nivel superior: En el diagrama de nivel superior

conclusión
desarrollo
objetivo
feeback
se plasman todos los procesos que describen al proceso principal. En
índice
inicio
este nivel los procesos no pueden interrelacionarse directamente, sino
que entre ellos siempre debe existir algún almacenamiento o entidad
externa que los una.
Nivel 2: Diagrama de detalle o expansión: A partir del nivel 2 de

detalle, los procesos pueden interrelacionarse directamente, sin
necesidad de almacenamiento que los una. Cabe destacar que en el
nivel 1 y 2 siempre los procesos deben tener las entradas y las salidas
dadas en el diagrama de contexto.
23
Niveles de DFD: Pasos para su construcción
Debe de indicar claramente dónde inicia y dónde termina el diagrama.

Cualquier camino del diagrama debe de llevarte siempre a la terminal de fin.
Organizar los símbolos de tal forma que siga visualmente el flujo de arriba
hacia abajo y de izquierda a derecha.
No usar lenguaje de programación dentro de los símbolos.
conclusión
desarrollo
objetivo
feeback
Centrar el diagrama en la página.
índice
inicio
Las líneas deben ser verticales u horizontales, nunca diagonales.
No cruzar las líneas de flujo empleando los conectores adecuados sin hacer
uso excesivo de ellos.
No fraccionar el diagrama con el uso excesivo de conectores.
Las líneas de flujo deben de entrar a un símbolo pro la parte superior y/o
izquierda y salir de él por la parte inferior y/o derecha.
Evitar que el diagrama sobrepase una página; de no ser posible, enumerar y
emplear los conectores correspondientes.
Comentar al margen únicamente cuando sea necesario.
24
conclusión
feeback
Esquema de Diagrama (DFD)
desarrollo
inicio
índice
25
objetivo
Esquema DFD: Diagrama de contexto
Proceso
Flujo
conclusión
desarrollo
objetivo
feeback
índice
inicio
Entidad
26
Esquema DFD: Diagrama de contexto
Se configura el diagrama de
contexto centrándose en los flujos
de datos de entrada y salida de las
entidades externas al proceso 0. Se
ha realizado una abstracción de
todos los informes que necesita la
dirección del videoclub (D.V) en el
conclusión
desarrollo
objetivo
feeback
flujo de datos Informes para
índice
inicio
simplificar el diagrama. La D.V
determina los pedidos de películas a
realizar a los proveedores mediante
el flujo de Datos de Pedido y
finalmente lo genera al proveedor
mediante el flujo Pedido. Este flujo
existe, ya que el sistema se encarga
de generar dicho pedido. Si lo
comunica la D.V al proveedor
directamente, este flujo no habría
que incluirlo. De forma similar
ocurriría con el flujo Pago.
27
Esquema DFD: Nivel 0
Almacén
Sub-proceso (Físico-digital)
conclusión
desarrollo
objetivo
feeback
Flujo entrada
índice
inicio
Flujo salida
28
A este nivel se abstraen las

funciones principales del sistema.
En este ejemplo, corresponden a la
gestión de clientes y a la gestión de
conclusión
proveedores. Vemos que la única
desarrollo
objetivo
feeback
comunicación existente entre
índice
inicio
ambos procesos es el almacén
Películas que tiene todos los datos
de las películas del videoclub, así
como sus ejemplares. También se
puede considerar la gestión de
bonos que se ocupa de generar el
almacén BONOS a partir de la
información proporcionada por la
dirección del videoclub.
29
Almacén
conclusión
desarrollo
objetivo
feeback
índice
inicio
Flujo salida
Flujo entrada
30
En este nivel incluimos las

funciones relativas a la gestión de
clientes.
Intentamos realizar una
abstracción de los procesos
conclusión
desarrollo
objetivo
feeback
relacionados con los clientes
índice
inicio
procurando no solapar
funcionalidades entre los
diferentes procesos (vemos que el
resultado lo constituyen procesos
independientes, pero todos
relacionados con los clientes).
31
Esquema DFD: Nivel 1.1
Almacén
conclusión
desarrollo
objetivo
feeback
índice
inicio
Flujo entrada
Flujo salida
32
Esquema DFD: Nivel 1.1
Descomponiendo la gestión de alquileres,

observamos tres procesos. El proceso 1.1.1
Validar Alquiler se va a ocupar de recoger el
Pedido de Alquiler y comprobar si el cliente tiene
conclusión
desarrollo
crédito, en cuyo caso acepta el alquiler y lo
objetivo
feeback
índice
inicio
almacena en ALQUILERES. A continuación
genera el comprobante, y para ello, debe
consultar la información de las películas
del almacén PELÍCULAS. Para generar la
información de los demás procesos, se puede
comprobar que sólo es necesaria la consulta del
almacén ALQUILERES, que es donde tenemos
almacenados los alquileres efectuados.
33
Ejercicio
Instrucciones:
Modelizar el sistema de información “Empresa de ventas de productos de limpieza"
utilizando la técnica de los diagramas de flujo de dato s (DFD). Obtener diagrama de
contexto, diagrama de nivel 1 y diagrama de nivel 2.
Caso:
conclusión
La actividad principal de la empresa objeto de estudio consiste en ofertar productos de
desarrollo
objetivo
feeback
limpieza. El funcionamiento es el siguiente:
índice
inicio
A partir del informe que envía el departamento de estudio de mercado de la empresa, se
contacta telefónicamente con los posibles clientes y se concierta con ellos una cita en la
empresa para ofertarles algún producto. Al contactar telefónicamente con ellos se les
toman sus datos personales para posteriormente realizar mailings de ofertas. También se
guardan los datos referentes a la cita. Para todas las citas concertadas se debe de realizar
un control de acceso de las visitas que básicamente consiste en: solicitar la identificación de
cualquier persona que acceda al recinto. No se permitirá entrar a ninguna persona que no
tenga cita previa. A las personas que tengan cita concertada se les entregará una tarjeta de
entrada, la cual deberán entregar a la salida firmada por el empleado al que han visitado.
Semanalmente los empleados de la empresa generan un informe detallado a partir de los
resultados obtenidos en las visitas realizadas que se envía al departamento de marketing
(para ello, primero se clasifican los resultados de las visitas por perfiles de empresa).
34
Ejercicio
Instrucciones:
Modelizar el sistema de información “Sistema de Servicios al Cliente en un Restaurante“
utilizando la técnica de los diagramas de flujo de dato s (DFD). Obtener diagrama de
contexto, diagrama de nivel contextual de nivel 0.
Caso:
conclusión
desarrollo
objetivo
feeback
A partir de una carta de platillos o especialidades de casa disponible en un repositorio
índice
inicio
virtual (inventario), un cliente solicita su orden de comida o pedido específico, se genera la
orden para cocina para el inicio de la preparación del platillo, actualiza la orden de
inventario, almacena los datos de la transacción; se procesa la información y se emite
factura al cliente. El sistema deberá generar reportes de los pedidos del inventario
disponible y de los datos de las transacciones generadas, información que será de utilidad
para el administrador del negocio. El administrador a través del sistema por podrá gestionar
una orden de inventario mediante repositorio del inventario de pedidos para obtener el
stock del inventario y requerir orden de comprar al proveedor.
35
conclusión
feeback Solución
desarrollo
inicio
índice
36
objetivo
conclusión
desarrollo
feedback
objetivo
El modelo de diagrama DFD pueden ser usados para representar el alcance del
índice
inicio
proyecto en varias vías, usted no necesita crear todos los modelos, considerar cuales
brindan la información más útil para cada proyecto. Herramienta tales como:
diagrama de contexto (DFD), mapa de ecosistema, árbol de características y lista de
eventos son para fomentar una comunicación clara y precisa entre los interesados en
el proyecto.
37

MÉXICO.
3. BRUEGGE BERND. (2002). INGENIERÍA DE SOFTWARE ORIENTADO A OBJETOS. :
bibliografía
conclusión
desarrollo
feedback
PEARSON EDUCACION, (2 Ejemplares disponibles en Biblioteca)
objetivo
índice
4. KARL WIEGERS & JOY BEATYY (2013). SOFTWARE REQUERIMENTS (Third Edition).
inicio
Microsfot Corporation
38
Ingeniería de
Requerimientos de
Software
UNIDAD 3: Especificación de Requerimiento de

Software (ERS)
TEMA 3: Análisis & Negociación de Requisitos

Perfiles públicos:
LinkendIn aquí.
Orcid: aquí.
2
Clase anterior… 1. Diagrama DFD

Diagrama de Flujo de Datos que podría
abarcar cualquier combinación de
software, hardware y componentes
humanos. KARL WIEGERS & JOY BEATYY
(2013)
conclusión
desarrollo
feedback
objetivo
2. Mapa Ecosistema
Técnica de
índice
inicio
Un mapa de ecosistemas muestra todos los

especificación sistemas relacionados con el sistema de interés
que interactúan entre sí y la naturaleza de esas
RQ interacciones (Beatty y Chen 2012).
3. Árbol de características
Un árbol de características es una descripción visual
de las características del producto organizadas en
grupos lógicos, subdividiendo jerárquicamente cada
característica en niveles adicionales de detalle
4. Lista de Eventos
Una lista de eventos identifica eventos externos que
podrían desencadenar un comportamiento en el
sistema.
3
Diagrama de Contexto (DFD)
Diagrama de contexto?
El "sistema" dentro del

círculo podría abarcar
cualquier combinación de
conclusión
desarrollo
software, hardware y
objetivo
feeback
índice
inicio
componentes humanos.
Las entidades externas en los
rectángulos pueden
representar clases de
usuarios (Chemist, Buyer),
organizaciones (Health and
Safety Department), otros
sistemas (Training Database)
o dispositivos de hardware
(Bar Code Reader).
Figura 5-6: Diagrama contextual parcial del Sistema de seguimiento de

4
Mapa de ecosistema
Mapa ecosistema?
Un mapa de ecosistemas
muestra todos los sistemas
relacionados con el sistema
conclusión
desarrollo
de interés que interactúan
objetivo
feeback
índice
inicio
entre sí y la naturaleza de
esas interacciones (Beatty y
Chen 2012).
Un mapa de ecosistema
representa el alcance al
mostrar todos los sistemas
que se interconectan y que,
por lo tanto, es posible que
deban modificarse para
adaptarse a su nuevo
sistema.
Figura 5-6: Mapa de ecosistema parcial del Sistema de seguimiento de
5
Árbol de características
Un árbol de características
es una descripción visual de
las características del
producto organizadas en
conclusión
grupos lógicos,
desarrollo
objetivo
feeback
subdividiendo
índice
inicio
jerárquicamente cada
característica en niveles
adicionales de detalle
El árbol de características
proporciona una vista
concisa de todas las
características planificadas
para un proyecto, lo que lo
convierte en un modelo ideal
Figura 5-8: Árbol de características parcial del Sistema de seguimiento de para mostrar a los ejecutivos
productos químicos, pág. 95. que desean echar un vistazo
Fuente: KARL WIEGERS & JOY BEATYY (2013). SOFTWARE REQUERIMENTS rápido al alcance del
(Third Edition). Microsfot Corporation. proyecto.
6
Lista de eventos
Una lista de eventos

identifica eventos externos
que podrían desencadenar
conclusión
un comportamiento en el
desarrollo
objetivo
feeback
sistema. La lista de eventos
índice
inicio
describe el límite del alcance
del sistema al nombrar
posibles eventos comerciales
activados por los usuarios,
eventos activados por el
tiempo (temporales) o
eventos de señal recibidos de
componentes externos,
Figura 5-9: Lista de eventos parcial del Sistema de seguimiento de como dispositivos de
productos químicos, pág. 96. hardware.
7
TEMA 3: Análisis y Negociación
conclusión
desarrollo
feedback
objetivo
 SUBTEMA 1: Criterios de aceptación de requerimientos.
índice
inicio
 SUBTEMA 2: Actividades de análisis y negociación de requerimientos.

 SUBTEMA 3: Reuniones de negociación.
 SUBTEMA 4: Priorización de requerimientos.
8
Analizar los requerimientos de software
conclusión
desarrollo
objetivo
concebidos en las etapas de obtención de
feeback
índice
inicio
requisitos mediante técnicas de análisis y

negociación para documentar las
especificaciones de requerimientos.
9
Términos: “Priorización de requerimientos,
Soporte Decisiones, Compensaciones”
conclusión
desarrollo
feedback
objetivo
índice
Qué es priorización? Quiénes toman las prioridades?
inicio
La priorización es un paso crucial para La priorización de las decisiones son
lograr buenas decisiones con respecto tomadas por los interesados,
a la planificación de productos para incluidos los usuarios,
lanzamientos únicos y múltiples… administradores, desarrolladores o sus
representantes…

10
Tomar de decisiones…
En la vida cotidiana, tomamos muchas decisiones,

p. Ej. al comprar un reproductor de DVD, comida,
un teléfono, ropa, etc. A menudo, ni siquiera somos
conclusión
conscientes de tomar una decisión. Por lo general,

desarrollo
feedback
objetivo
lo hacemos. No tener más de un par de opciones
índice
inicio
para considerar, como qué marca de mostaza
comprar, o si tomar este bus o el siguiente.
Incluso con solo un par de opciones, las decisiones

pueden ser difíciles de tomar. Al tener decenas,
centenas o incluso miles de alternativas, la toma
de decisiones se vuelve mucho más difícil…
11
Priorizar entre varias alternativas…
Una de las clave para tomar la decisión correcta

es priorizar entre diferentes
alternativas. A menudo no es obvio cuál es la
conclusión
mejor opción, porque varios aspectos

desarrollo
feedback
objetivo
debe tenerse en cuenta. Por ejemplo, al comprar
índice
inicio
un automóvil nuevo, es relativamente
fácil hacer una elección basada solo en la
velocidad (solo se necesita evaluar
qué coche es el más rápido). Al considerar
múltiples aspectos, como: precio, seguridad,
comodidad, o carga de equipaje, la elección se
vuelve mucho más difícil…
12
Priorizar entre varias alternativas…
Al desarrollar sistemas de software, deben

realizarse compensaciones similares. La
funcionalidad que es más
conclusión
importante para los clientes puede no ser tan

desarrollo
feedback
objetivo
importante cuando otros aspectos
índice
inicio
(p. Ej. precio) se tienen en cuenta. Necesitamos
desarrollar la funcionalidad que más desea
los clientes, así como los menos riesgosos, menos
costosos, etc.
La priorización ayuda a hacer frente a estos
complejos problemas de decisión…
13
conclusión
feedback
Reuniones de Negociación
desarrollo
inicio
índice
14
objetivo
Priorización & Negociación
¿Qué pasa si no puede llegarse a unacuerdo con

el cliente en algún aspecto relacionado con el proyecto?
conclusión
desarrollo
objetivo
feeback
índice
inicio
La negociación no es un concurso o un
juego. Funciona mejor cuando las dos
partes ganan. Hay muchas circunstancias en
las que usted y otros participantes deben
negociar: funciones y características,
prioridades y fechas de entrega. La
negociación demandará el compromiso de
todas las partes.
15
Priorización & Negociación
En lugar de una sola actividad de comunicación con el cliente, se
definen las actividades siguientes:
01
conclusión
desarrollo
Identificación de los participantes clave del
objetivo
feeback
sistema o subsistema
índice
inicio
02
Determinación de las “condiciones para
ganar” de los participantes
03
Negociación de las condiciones para ganar de
los participantes. Ganar-ganar para todos.
Boehm, B., “Using the WINWIN Spiral Model: A Case Study”, Computer, vol. 31, núm. 7, julio 1998 pp. 33-44.
16
Arte de la negociación
Reconocer que no es una competencia

Para tener éxito, ambas partes tienen que sentir que han
ganado o logrado algo. Las dos tienen que llegar a un
compromiso.
conclusión
desarrollo
objetivo
feeback
Mapear una estrategia
índice
inicio
Decidir qué es lo que le gustaría lograr; qué quiere
obtener la otra parte y cómo hacer para que ocurran las
dos cosas.
Escuchar activamente
No trabaje en la formulación de su respuesta mientras la
otra parte esté hablando. Escúchela.
Centrarse en los
intereses de la otra parte
Si quiere evitar conflictos, no adopte posiciones
inamovibles.
17
Arte de la negociación
No lo tome en forma personal

Céntrese en el problema que necesita resolverse.
conclusión
desarrollo
objetivo
feeback
Sea creativo
índice
inicio
Si están empantanados, no tenga miedo de pensar
fuera de los moldes.
Esté listo para comprometerse

Una vez que se llegue a un
acuerdo, no titubee; comprométase con él y cúmplalo.
18
conclusión
feedback
El proceso de priorizar
desarrollo
inicio
índice
19
objetivo
Proceso de priorización
El proceso de priorizar los requisitos proporciona apoyo para lo siguiente actividades:
Para qué?
• Para que las partes interesadas decidan sobre los requisitos
básicos del sistema.
conclusión
desarrollo
• Para planificar y seleccionar un conjunto óptimo ordenado de
objetivo
feeback
índice
requisitos de software para la implementación en
inicio
lanzamientos sucesivos.
• Para compensar el alcance del proyecto deseado con
restricciones a veces conflictivas como: cronograma,
presupuesto, recursos, tiempo de comercialización y calidad.
• Para equilibrar el beneficio comercial de cada requisito con su
costo.
• Para equilibrar las implicaciones de los requisitos en la
arquitectura del software y la futura evolución del producto y
su coste asociado.
20
Proceso de priorización
El proceso de priorizar los requisitos proporciona apoyo para lo siguiente actividades:
Para qué?
• Para seleccionar solo un subconjunto de los requisitos y aún
así producir un sistema que satisfacer al (los) cliente(s).
conclusión
desarrollo
objetivo
feeback
• Para estimar la satisfacción esperada del cliente.
índice
inicio
• Para obtener una ventaja técnica y optimizar la oportunidad de
mercado.
• Para minimizar la repetición de trabajos y el deslizamiento del
programa (estabilidad del plan).
• Para manejar requisitos contradictorios, enfocar el proceso de
negociación y resolver desacuerdos entre las partes
interesadas.
• Para establecer la importancia relativa de cada requisito para
proporcionar la mayor valor al menor costo.
21
Priorizar, proceso estratégico…
La lista anterior muestra claramente la importancia de priorizar y

decidir qué requisitos para incluir en un producto. Este es un proceso
estratégico, estas decisiones impulsan los gastos de desarrollo y los
ingresos del producto, así como diferencia entre ganancia y pérdida de
mercado. Además, el resultado de la priorización puede constituir la
conclusión
desarrollo
objetivo
feeback
base de los planes de marketing y productos, además de ser un fuerza
índice
inicio
impulsora durante la planificación del proyecto.
Ruhe et. al. resume esto como: "El desafío es seleccionar los requisitos
"correctos" de un superconjunto dado de requisitos candidatos de
modo que todos los diferentes intereses clave, limitaciones técnicas y
preferencias de las partes interesadas críticas se cumplen y el valor
comercial general del producto se maximiza”
22
Rectificar decisiones…
Por supuesto, es posible rectificar decisiones incorrectas más adelante

mediante la gestión de cambios, pero esto puede ser muy
costoso ya que es significativamente más costoso corregir problemas
más adelante en el desarrollo proceso.
conclusión
desarrollo
objetivo
feeback
índice
inicio
Frederick P. Brooks lo expresa con las siguientes palabras: “El La parte
más difícil de la construcción de un sistema de software es decidir con
precisión qué construir. […] Ninguna otra parte del trabajo paraliza
tanto el sistema resultante si se hace incorrecto. Ninguna otra parte es
más difícil de rectificar más adelante ”
23
Resumen
Una forma eficaz de desarrollar software es encontrar el conjunto

óptimo de requisitos. temprano, y luego desarrollar el software de
acuerdo con este conjunto. Para lograr esto, es fundamental priorizar
los requisitos para permitir la selección del conjunto óptimo.
conclusión
desarrollo
objetivo
feeback
índice
inicio
Además de los beneficios obvios presentados anteriormente, la
priorización de requisitos puede tiene otros beneficios. Por ejemplo,
es posible encontrar defectos en los requisitos (p. Ej. requisitos mal
juzgados, incorrectos y ambiguos), debido que los requisitos se
analizan desde una perspectiva diferente a la tomada durante las
revisiones de los requisitos.
24
conclusión
feedback
Aspectos de priorización
desarrollo
inicio
índice
25
objetivo
Los requisitos se pueden priorizar teniendo en cuenta

muchos aspectos diferentes. Un aspecto es una propiedad
o atributo de un proyecto y sus requisitos que se pueden
utilizar para priorizar los requisitos. Los aspectos comunes
conclusión
desarrollo
objetivo
feeback
son: importancia, penalización, costo, tiempo, y riesgo.
índice
inicio
Importancia Penalización Costo Tiempo Riesgo
26
Al priorizar la importancia, las partes

interesadas deben priorizar qué requisitos son
los más importantes para el sistema. Sin
embargo, la importancia podría ser
conclusión
desarrollo
extremadamente concepto multifacético,
objetivo
feeback
índice
inicio
debido que depende en gran medida de qué
perspectiva la parte interesada tiene. La
importancia podría ser, por ejemplo: la urgencia
de la implementación, importancia de un
requisito para la arquitectura del producto,
Importancia importancia estratégica para la empresa, etc. En
consecuencia, es fundamental especificar qué
tipo de importancia las partes interesadas
deben priorizar en cada caso.
27
Es posible evaluar la penalización que es

introducida si no se cumple un requisito.
La penalidad no es justamente lo contrario a la
importancia.
conclusión
desarrollo
Por ejemplo, no cumplir con un estándar podría
objetivo
feeback
índice
inicio
incurrir en una alta penalización incluso si es de
poca importancia para el cliente
(es decir, el cliente no se emociona si se cumple
el requisito).
Penalización Lo mismo ocurre con los requisitos implícitos
que los usuarios dan por sentado y cuya
ausencia podría hacer que el producto no sea
adecuado para el mercado.
28
El costo de implementación generalmente lo

estima la organización en desarrollo.
Las medidas que influyen en el costo incluyen:
complejidad del requisito, capacidad para
conclusión
desarrollo
reutilizar el código existente, la cantidad de
objetivo
feeback
índice
inicio
pruebas y documentación necesarias, etc.
El costo a menudo se expresa en términos de
horas de personal (esfuerzo) debido que el
costo principal en software, el desarrollo suele
Costo estar relacionado principalmente con el número
de horas dedicadas. Costo (como
así como el tiempo, podría priorizarse utilizando
simplemente estimando el costo real en un
valor absoluto o escala normalizada.
29
Como se puede ver en el aspecto anterior, el

costo del desarrollo de software a menudo está
conclusión
desarrollo
objetivo
relacionado al número de horas del personal.
feeback
índice
inicio
Sin embargo, el tiempo (es decir, el tiempo de
entrega) está influenciado por muchos
otros factores como: el grado de paralelismo en
Tiempo el desarrollo, las necesidades de formación, la
necesidad de desarrollar infraestructura de
apoyo, estándares industriales completos.
30
Cada proyecto conlleva cierto riesgo. En gestión de
proyectos, gestión de riesgos se utiliza para hacer
frente tanto a riesgos internos (técnicos y de
mercado) como externos riesgos (regulaciones,
proveedores). Se deben considerar tanto la
conclusión
desarrollo
probabilidad como el impacto al determinar el
objetivo
feeback
índice
inicio
nivel de riesgo de un artículo o actividad.
Gestión de riesgos también se puede utilizar al
planificar los requisitos en productos y versiones
identificando riesgos que probablemente causen
dificultades durante el desarrollo. Tal los riesgos
Riesgo podrían incluir, por ejemplo: riesgos de
rendimiento, riesgos de proceso, riesgos de
programación. Basado en la probabilidad de riesgo
estimada y el impacto del riesgo para cada
requisito, es posible calcular el nivel de riesgo de un
proyecto.
31
Otros aspectos de priorización
La volatilidad de los requisitos se considera un
factor de riesgo y a veces se maneja como
parte del aspecto del riesgo. Las razones de la
volatilidad de los requisitos varían, por ejemplo: el
mercado cambia, los requisitos comerciales
conclusión
desarrollo
cambian, los cambios legislativos ocurren, los
objetivo
feeback
índice
inicio
usuarios cambian o los requisitos se vuelven más
claros durante el ciclo de vida del software.
Independientemente del motivo, los requisitos
volátiles afectan la estabilidad y planificación de un
proyecto, y presumiblemente aumentar los costos
Volatilidad debido que los cambios durante el desarrollo
aumentar el costo de un proyecto.
Ejemplos de otros aspectos son: beneficio
financiero, beneficio estratégico, competidores,
competencia / recursos, tema de lanzamiento,
capacidad de venta, etc.
32
conclusión
feedback
Técnicas y métodos de priorización
desarrollo
inicio
índice
33
objetivo
Escalas de medición…
El propósito de cualquier priorización es asignar valores a

distintos objetos de priorización que permiten el
establecimiento de un orden relativo entre los objetos del
conjunto. En nuestro caso, los objetos son los requisitos a
conclusión
desarrollo
priorizar.
objetivo
feeback
índice
inicio
La priorización puede ser hecho con varias escalas y tipos de medición:
 Escala ordinal, donde los requisitos se ordenan de modo que sea

posible para ver qué requisitos son más importantes que otros, pero no
cuánto más importante. (la escala 1, 2, 3, n-1, n…)
 Escala de proporción, cuantificar cómo mucho más importante es un
requisito que otro (la escala suele oscilar entre 0-100 por ciento).
 Escala absoluta: se utiliza en situaciones en las que se puede asignar un
número absoluto (por ejemplo, número de horas).
34
Proceso de Jerarquía Analítica (AHP)
Analytical Hierarchy Process (AHP), es un método sistemático

de toma de decisiones que se ha adaptado para priorizar los
requisitos de software. Usar AHP para la toma de decisiones
conclusión
desarrollo
implica cuatro pasos. (Ver más detalle.)
objetivo
feeback
índice
inicio
Asumiremos aquí que desea evaluar los requisitos de los
candidatos utilizando el criterio de valor.
Decidir qué requisitos realmente importan es una tarea difícil

y uno cada vez más demandado debido a limitaciones de
tiempo y presupuesto.
35
Proceso de Jerarquía Analítica (AHP) Pasos
Paso 1: Configure los n requisitos en las filas y columnas de un

n x n matriz. Asumiremos aquí que tiene cuatro candidatos
requisitos: Req1, Req2, Req3 y Req4, y desea conocer su valor
conclusión
desarrollo
relativo. Inserte los requisitos n en el filas y columnas de una
objetivo
feeback
índice
inicio
matriz de orden n (en este caso tenemos una matriz de 4 x 4).
36
Paso 2: Paso 2. Realizar comparaciones por pares de todos los

requisitos de acuerdo con el criterio. La escala fundamental
utilizada para este propósito se muestra en la Tabla A.1 Para
cada par de requisitos (comenzando con Req1 y Req2, por
conclusión
desarrollo
ejemplo) inserte su determinada intensidad relativa de valor
objetivo
feeback
índice
inicio
en la posición (Req1, Req2) donde la fila de Req1 cumple la
columna de Req2. En la posición (Req2, Req1) inserte el valor
recíproco, y en todas las posiciones de la diagonal principal
inserte un "1". Continúe realizando comparaciones por pares
de Req1 – Req3, Req1 – Req4, Req2 – Req3, y así
sucesivamente. Para una matriz de orden n, n*(n-1)/2
se requieren comparaciones. Por tanto, en este ejemplo, seis
pares se requieren comparaciones; podrían verse así:
37
conclusión
feeback Proceso de Jerarquía Analítica (AHP) Pasos
desarrollo
inicio
índice
38
objetivo
conclusión
feeback Proceso de Jerarquía Analítica (AHP) Pasos
desarrollo
inicio
índice
39
objetivo
Paso 3: Utilice el promedio sobre columnas normalizadas para

estimar el valores propios de la matriz (que representan la
distribución de criterio). Thomas Saaty propone un método
simple para esto, conocido como promediar sobre columnas
conclusión
desarrollo
normalizadas.1 Primero, calcule la suma de las n columnas en
objetivo
feeback
índice
inicio
la matriz de comparación. A continuación, divida cada
elemento de la matriz por la suma de los columna de la que es
miembro el elemento, y calcular las sumas de cada fila:
40
Luego normaliza la suma de las filas (divide cada fila

suma con el número de requisitos). El resultado de esto
El cálculo se conoce como matriz de prioridades y es una
estimación de los valores propios de la matriz.
conclusión
desarrollo
objetivo
feeback
índice
inicio
Matriz de
prioridades
41
Paso 4: Asigne a cada requisito su valor relativo basado en los

valores propios estimados. A partir de los valores propios
resultantes de la matriz de comparación, se puede obtener la
siguiente información extraído:
conclusión
desarrollo
objetivo
feeback
índice
inicio
 Req1 contiene el 26 por ciento del valor total de los requisitos,
 Req2 contiene el 50 por ciento,
 Req3 contiene un 9 por ciento y
 Req4 contiene 16 por ciento.
42
Índice de consistencia: El índice de coherencia (IC) es un

primer indicador de la precisión de los resultados de las
comparaciones por pares. Lo calculas como CI= (max-n)/(n-1),
max denota el valor propio principal máximo de la matriz de
conclusión
desarrollo
comparación. Cuanto más cerca esté el valor de n (el número
objetivo
feeback
índice
inicio
de requisitos), menores serán los errores de juicio y, por tanto,
más coherente será el resultado. Para estimar, primero
multiplica la matriz de comparación por el vector de prioridad:
43
Luego divide el primer elemento del vector resultante por

el primer elemento en el vector de prioridad, el segundo
elemento de el vector resultante por el segundo elemento en
la prioridad vector, y así sucesivamente:
conclusión
desarrollo
objetivo
feeback
índice
inicio
44
Para calcular max, promedia los elementos del vector

resultante:
conclusión
desarrollo
objetivo
feeback
índice
inicio
Ahora se puede calcular el índice de consistencia:
Para saber si el índice de consistencia resultante (IC =

0,12) es aceptable, debe calcular el índice de
consistencia.
45
Relación de consistencia (RC o CR): Los índices de consistencia

de matrices recíprocas generadas aleatoriamente de la escala
1 a 9 se denominan índices aleatorios (RI). La relación de CI a
RI para la matriz del mismo orden se denomina relación de
conclusión
desarrollo
consistencia (CR), que define la precisión de las
objetivo
feeback
índice
inicio
comparaciones por pares. El RI para matrices de orden n se da
a continuación. La primera fila muestra el orden de la matriz,
y el segundo el valor RI correspondiente.
46
Según la Tabla A, el IR para matrices de orden 4 es 0.90. Por lo

tanto, la relación de consistencia para nuestro ejemplo es:
conclusión
desarrollo
objetivo
feeback
índice
inicio
Como regla general, una relación de consistencia de 0.10
o menos se considera aceptable. Esto significa que
nuestro resultado aquí es mayor que ideal. En la práctica,
sin embargo, se producen con frecuencia relaciones de
consistencia superiores a 0,10.
47
Cumulative Voting, the 100-Dollar Test
La prueba de los 100 dólares es una técnica de priorización muy sencilla en

la que los interesados reciben 100 unidades imaginarias (dinero, horas,
etc.) para distribuir entre los requisitos. El resultado de la priorización se
presenta en una proporción escala. Un problema con esta técnica surge
cuando hay demasiados requisitos para priorizar. Por ejemplo, si tiene 25
conclusión
desarrollo
objetivo
feeback
requisitos, hay un promedio de cuatro puntos a distribuir para cada
índice
inicio
requerimiento. Regnell et. al. enfrentó este problema cuando había 17
grupos de requisitos para priorizar. En el estudio, utilizaron un
cantidad ficticia de $ 100,000 para tener más libertad en las priorizaciones.
Los sujetos del estudio fueron positivos sobre la técnica, lo que indica la
posibilidad utilizar cantidades distintas de 100 unidades (por ejemplo,
1.000, 10.000 o 1.000.000). Otro posible problema con la prueba de 100
dólares (especialmente cuando hay muchos requisitos) es que la persona
que realiza la priorización calcula mal y los puntos no suman 100. Esto se
puede prevenir usando una herramienta que mantiene recuento de
cuántos puntos se han utilizado.
48
Asignación numérica (agrupación)
La asignación numérica es la técnica de priorización más común y se

sugiere tanto en RFC 2119 como en IEEE Std. 830-1998. El enfoque se basa
sobre la agrupación de requisitos en diferentes grupos prioritarios. El
número de grupos puede varían, pero en la práctica, tres grupos son muy
comunes. Cuando se usa numérico asignación, es importante que cada
conclusión
desarrollo
objetivo
feeback
grupo represente algo que el las partes interesadas pueden relacionarse
índice
inicio
(por ejemplo, crítico, estándar, opcional), para una clasificación confiable.
El uso de términos relativos como alto, medio y bajo confundirá a las

partes interesadas. Esto parece ser especialmente importante cuando hay
partes interesadas con diferentes visiones de lo que significa alto, medio y
bajo. Una definición clara de lo que realmente significa un grupo minimiza
tales problemas.
49
Asignación numérica (agrupación)
Otro problema potencial es que las partes interesadas tienden a pensar

que todo está crítico. Si los clientes se priorizan a sí mismos, utilice tres
grupos; crítico, estándar y opcional, lo más probable es que consideren el
85% de los requisitos como crítico, 10% como estándar y 5 % como
opcional. Uno La idea es poner restricciones sobre el número permitido de
conclusión
desarrollo
objetivo
feeback
requisitos en cada grupo. (por ejemplo, no menos del 25% de los requisitos
índice
inicio
en cada grupo). Sin embargo,
Un problema con este enfoque es que la utilidad de las prioridades
disminuye porque las partes interesadas se ven obligadas a dividir los
requisitos en ciertos grupos. Sin embargo, no hay evidencia empírica de
buenos o malos resultados con tales restricciones. existe. El resultado de la
asignación numérica son requisitos priorizados en un ordinal escala. Sin
embargo, los requisitos en cada grupo tienen la misma prioridad, que
significa que cada requisito no tiene una prioridad única.
50
Ranking
Como en la asignación numérica, la clasificación se basa en una escala

ordinal, pero los requisitos están clasificados sin empates en el rango. Esto
significa que el requisito más importante se clasifica 1 y el menos
importante se clasifica n (para n requisitos).
conclusión
desarrollo
objetivo
feeback
Cada requisito tiene un rango único (en comparación con la asignación
índice
inicio
numérica) pero no es posible ver la diferencia relativa entre los elementos
clasificados (como en AHP o la prueba de los 100 dólares). La lista de
requisitos clasificados se puede obtener en un variedad de formas, como
por ejemplo mediante el uso de la clasificación de burbujas o los
algoritmos de árbol de búsqueda binaria.
Independientemente del algoritmo de clasificación, la clasificación parece

ser más adecuada para una sola parte interesada porque puede resultar
difícil alinear varios opiniones de las partes interesadas.
51
Diez requisitos principales (Top-Ten)
En el enfoque de los diez requisitos principales, las partes interesadas
eligen sus diez requisitos principales (de un conjunto mayor) sin asignar
una orden interno entre los requisitos. Esto hace que el enfoque sea
especialmente adecuado para múltiples partes interesadas de
igual importancia. La razón para no priorizar más es que podría crear
conclusión
desarrollo
conflicto innecesario cuando algunas partes interesadas obtienen apoyo
objetivo
feeback
índice
inicio
para su máxima prioridad y otros solo por su tercera prioridad. Se podría
suponer que podrían surgir conflictos de todos modos si, por ejemplo, un
cliente obtiene tres requisitos de los diez primeros en el producto
mientras que otro obtiene seis requisitos de los diez primeros en el
producto. De todos modos, eso Es importante no solo tomar un promedio
de todas las partes interesadas, ya que podría conducir a algunas partes
interesadas que no obtienen ninguno de sus principales requisitos. En
cambio, es crucial que se cumplan algunos requisitos esenciales para cada
parte interesada. Esta obviamente, podría resultar en una situación que no
satisfaga a todos los clientes en lugar de satisfacer unos pocos clientes por
completo. El principal desafío de esta técnica es equilibrar estos asuntos.
52
¿Qué técnica de priorización elegir?
Resume las técnicas de priorización presentadas, basadas en

la medición escala, granularidad del análisis y nivel de
sofisticación de la técnica:
Técnica Escala Granularidad Sofisticación
conclusión
desarrollo
objetivo
feeback
AHP Ratio Bien Muy compleja
índice
inicio
Prueba de 100 Ratio Bien Compleja
dólares
Ranking Ordinal Media Fácil
Asignación Ordinal Gruesa Muy Fácil
numérica
Top-Ten - Extremadamen Extremadamen
te gruesa te Fácil.
53
Un consejo general es utilizar la técnica de priorización

apropiada más simple y utilizar los más sofisticados cuando se
necesita un análisis más sensible para resolver desacuerdos o
para apoyar las decisiones más críticas.
conclusión
Como mas sofisticado Las técnicas generalmente consumen
desarrollo
objetivo
feeback
índice
inicio
más tiempo, la técnica más simple posible asegura decisiones
rentables. La compensación es decidir exactamente cómo
“Rápido y sucio” el enfoque puede ser sin dejar que la calidad
de las decisiones sufrir.
Cabe destacar también que existen varias herramientas
comerciales que facilitan el uso de técnicas más sofisticadas
(por ejemplo, AHP) y que es posible construir herramientas
sencillas hechas en casa (por ejemplo, en hojas de cálculo)
para facilitar el uso de diferentes técnicas de priorización.
54
conclusión
desarrollo
feedback
objetivo
índice
inicio
Partes involucradas en el proceso de
priorización
55
Diferencias entre desarrollo
impulsado por el mercado y desarrollado a medida
En un proyecto a medida, solo una o algunas partes

interesadas debe tenerse en cuenta mientras que todos en el
conclusión
desarrollo
objetivo
mundo entero servir como clientes potenciales en el
feeback
índice
inicio
desarrollo impulsado por el mercado. Esquemas de la tabla
algunas de las diferencias entre el desarrollo impulsado por el
mercado y el desarrollo a medida que afecta priorización de
requisitos.
56
Faceta Desarrollo a medida Desarrollo impulsado
por el mercado
Grupo de interés Organización del cliente Organización en
principal desarrollo
conclusión
desarrollo
objetivo
feeback
Usuarios Conocidos e Desconocidos, puede
índice
inicio
identificables que no existan hasta
que el producto este en
el mercado
Distancia a los usuarios Generalmente pequeña Generalmente grande
Concepción de Obtenido, analizado, Inventado (por atracción
requisitos validado del mercado o empuje
tecnológico)
Ciclo de vida Una versión, luego Varios lanzamientos
mantenimiento siempre que exista
demanda del mercado
57
Faceta Desarrollo a medida Desarrollo impulsado
por el mercado
Problemas específicos Obtención, modelado y Flujo constante de
ERS validación, resolución de requisitos, priorización,
conclusión
desarrollo
conflictos estimación de costos,
objetivo
feeback
índice
inicio
planificación de
lanzamiento.
Objetivo principal Cumplimiento de las Tiempo de
especificaciones comercialización
Medidas de éxito Satisfacción, aceptación Ventas, cuotas de
mercado
58
conclusión
feedback
Ejemplo de priorización
desarrollo
inicio
índice
59
objetivo
Aspectos a priorizar
Para ilustrar los diferentes aspectos, técnicas de priorización,
compensaciones entre partes interesadas, y combinaciones de técnicas
y aspectos de priorización, un ejemplo de una situación de priorización.
El método utilizado en este ejemplo está influenciado por un modelo
propuesto por Wiegers pero está diseñado para ajustarse a este
conclusión
desarrollo
ejemplo. Los ejemplo analiza 15 requisitos (R1-R15) en una situación con
objetivo
feeback
índice
inicio
tres clientes conocidos (ver 4.5.2). El análisis es bastante sofisticado para
mostrar diferentes problemas en priorización pero aún simple con una
pequeña cantidad de requisitos. Mientras que muchos más requisitos
son comunes en la industria, es más fácil ilustrar cómo las técnicas
trabajar en un ejemplo más pequeño. Cada uno de los 15 requisitos se
prioriza según a los diferentes aspectos. Ver Tabla a continuación
presenta los aspectos que se utilizan en el ejemplo junto con el método
que se utiliza para priorizar el aspecto y desde qué perspectiva se
prioriza.
60
Aspectos a priorizar
Aspectos Técnicas de priorización Perspectivas

Importancia estratégica AHP Administrador del
producto
Importancia del cliente 100-Dollar/Top-Ten Clientes
conclusión
desarrollo
objetivo
feeback
Penalidad AHP Administrador del
índice
inicio
producto
Costo 100-Dollar Desarrolladores
Tiempo Asignación numérica Administrador de
Proyecto
Riesgo Asignación numérica Especialista en
requerimientos
Volatilidad Ranking Especialista en
requerimientos
61
Ejemplo: Priorización
Para que las priorizaciones sean más efectivas, los requisitos se refinan
aún más. Primero, los requisitos R1 y R2 son requisitos absolutamente
necesarios para hacer que el sistema funcione en absoluto. Por tanto, no
son priorizados por los clientes sino se estiman en términos de costo,
riesgo, etc., ya que R1 y R2 influyen estas variables no importa qué. Esta
conclusión
desarrollo
es una forma de utilizar el enfoque de clasificación de requisitos
objetivo
feeback
índice
inicio
presentado. Además, se han establecido dos grupos de requisitos
identificados como de alto nivel de dependencia (deben implementarse
juntos) y, por lo tanto, deben priorizarse juntos. Los requisitos R3, R4 y
R5 están agrupados juntos como R345, y los requisitos R6 y R7 se
agrupan en R67.
62
Ejemplo:
Tabla - Priorización de resultados de importancia estratégica y para el cliente.
Prioridad, P (RX) = RPC1 × WC1 + RPC2 × WC2 + RPC3 × WC3 + RPPM × WPM,
donde RP es la prioridad del requisito, y W es el peso de la parte interesada
conclusión
desarrollo
objetivo
feeback
índice
inicio
63
Ejemplo:
Tabla - Descending priority list based on importance and penalty (IP). IP(RX) = RPI
× WI + RPP × WP, where RP is the requirement priority, and W is the weight of
Importance (I) and Penalty (P)
conclusión
desarrollo
objetivo
feeback
índice
inicio
64
Criterio de selección
Requerimientos seleccionados basado en el índice de prioridad y costo.
conclusión
desarrollo
objetivo
feeback
índice
inicio
La tabla muestra que logramos ajustarnos a las restricciones de costos, pero no
pudimos satisfacer la restricción de riesgo. Como resultado, el proyecto se vuelve
demasiado riesgoso. En cambio, otro se adopta un enfoque para encontrar una
colección adecuada de requisitos. En este enfoque, tomamos en consideración la
relación IP / Costo. Esto muestra qué requisitos proporcionar la mayor parte de la
propiedad intelectual al menor costo. En este caso, intentamos establecer un límite
de solo seleccionar requisitos que tengan una relación IP / costo superior a 1.0.
65
Criterio de selección
Requisitos seleccionados basados en el costo y la relación IP / costo.
conclusión
desarrollo
objetivo
feeback
índice
inicio
La tabla muestra que las restricciones de costos aún se cumplen (incluso nueve por
ciento menos costo) al tiempo que satisface la restricción de riesgo. Comparación
de tablas anterior y esta muestra que el valor de IP de la segunda solución
candidata es mayor que indica que los clientes están más satisfechos con el
producto y la relación IP / costo es casi el doble. La segunda solución candidata
satisface el 91 por ciento (2,73 / 3) del aspecto IP, en comparación con el 83 por
ciento en la primera solución candidata. El hecho que la segunda alternativa cuesta
menos y es menos arriesgada también favorece esta elección.
66
[Actividad: Tarea ]
A partir de la siguiente actividad, Tarea N° 4 : Práctica, caracterizar escenarios y
casos de uso, permite profundizar en obtener y analizar información relacionada
al modelo de negocio previo al desarrollo de un sistema mediante la aplicación de
conclusión
técnicas de ingeniería de requerimientos software vinculación a: procesos de
desarrollo
objetivo
feeback
ingeniería de requerimientos, adquisición y análisis de requerimiento en el
índice
inicio
contexto de la ingeniería de software.
Tema: Elaboración de la especificación de requerimiento (ERS), se

recomienda: Analiza, reflexionar, debatir entre los integrantes del equipo
respecto al modelo de negocio a seleccionar. Considerar que el software
resuelva un problema en el campo: salud, comercial o educativo, en el
contexto de la pandemia Covid-19.
Instrucciones:
 Descarga la guía de Recurso de Aprendizaje Tarea aquí.
Actividad: Evaluable
67
Este capítulo ha presentado una serie de técnicas, aspectos y
otras cuestiones que debe tenerse en cuenta al realizar las
conclusión
priorizaciones. Estas diferentes partes juntas Formar una base
desarrollo
feedback
objetivo
para priorizar sistemáticamente los requisitos durante el
índice
inicio
desarrollo de software. El resultado de las priorizaciones sugiere
qué requisitos deben implementado y en qué versión. Por tanto,
las técnicas podrán ser valiosas ayudar a las empresas a
comprender qué es importante y qué no para un proyecto o un
producto. Como ocurre con todos los métodos de evaluación, los
resultados deben interpretarse y posiblemente ajustado por
tomadores de decisiones informados en lugar de simplemente
aceptado como decisión final.
Fuente: Aybüke Aurum · Claes Wohlin
68
1. BRUEGGE BERND. (2002). INGENIERÍA DE SOFTWARE ORIENTADO A OBJETOS. :

PEARSON EDUCACION
bibliografía
conclusión
desarrollo
feedback
objetivo
índice
inicio
MÉXICO.
4. PRESSMAN, ROGER S. (2010). INGENIERÍA DEL SOFTWARE. MEXICO: MCGRAW-

HILL.
5. IEEE, COMPUTER SOCIIETY (2014). SWEBOK. GUIDE TO THE SOFTWAR
ENGIEERING BODY OF KNOWLEDGE, VERSION 3.0
6. AYBÜKE AURUM · CLAES WOHLIN (2005). ENGINEERING AND MANAGING
SOFTWARE REQUIREMENTS. SPRINGER-VERLAG, GERMANY.
69
Ingeniería de
Requerimientos de
Software

software (ERS)
TEMA 4: Documentación de Especificación de

requerimientos (ERS)

Perfiles públicos:
LinkendIn aquí.
Orcid: aquí.
2
Clase anterior…
conclusión
desarrollo
feedback
objetivo
índice
inicio
Importancia Penalización Costo Tiempo Riesgo
3
Clase anterior…
Técnica Escala Granularidad Sofisticación

conclusión
desarrollo
feedback
objetivo
índice
inicio
AHP Ratio Bien Muy compleja

Prueba de 100 Ratio Bien Compleja
dólares
Ranking Ordinal Media Fácil
Asignación Ordinal Gruesa Muy Fácil
numérica
Top-Ten - Extremadamen Extremadamen
te gruesa te Fácil.
4
Clase anterior…
RQ
No software
Funcionales
conclusión
desarrollo
feedback
objetivo
índice
inicio

Negocio de software
Alcance,
Documento
restricciones
(escrito)
5
TEMA 4: Documentación de Especificación
de requerimientos (ERS)
conclusión
desarrollo
feedback
objetivo
 SUBTEMA 1: Introducción (propósito, alcance, roles, etc.)
índice
inicio
 SUBTEMA 2: Descripción general (perspectiva, funcionalidad,

restricciones, etc.)
 SUBTEMA 3: Requisitos específicos (funcionales, no funcionales)
 SUBTEMA 4: Documentación de especificación de requerimientos (ERS)
6
Documentar la especificación de los
requerimientos de software concebidos en las
conclusión
desarrollo
objetivo
feeback
etapas de obtención de requisitos mediante
índice
inicio
técnicas de análisis y negociación
7
Términos: “ERS”
Qué son las siglas ERS? Para que nos sirve el ERS?
conclusión
desarrollo
feedback
objetivo
índice
Este enfoque formal (ERS) es
inicio
Especificación de requerimiento de
software adecuado para sistemas
empresariales donde los
requerimientos son inestables. Sin
embargo, aún resulta útil escribir un
breve documento de apoyo que
defina los requerimientos de la
empresa y los requerimientos de
confiabilidad para el sistema…

8
conclusión
feeback
Documento de
desarrollo
inicio
índice
9
objetivo
Algunas organizaciones grandes,

conclusión
desarrollo
como el Departamento de Defensa
objetivo
feeback
índice
inicio
estadounidense y el Institute of
Electrical and Electronic
Engineers (IEEE), definieron
estándares para los documentos
de requerimientos. Descarga formato aquí
Fuente: Página especificación estándar
10
La especificación de requisitos de software tiene muchos nombres en

varias organizaciones, aunque las organizaciones no usan estos términos
de la misma manera.
conclusión
desarrollo
objetivo
feeback
índice
inicio
A veces se denomina documento de requisitos empresariales (BRD),
especificación funcional, especificación de producto, especificación de
sistema o simplemente documento de requisitos. Debido a que
"especificación de requisitos de software" es un término estándar de la
industria, así lo llamaremos aquí (ISO / IEC / IEEE 2011).
11
Importante:
 Los requisitos entregables a menudo no pueden satisfacer las
necesidades de todos los públicos.
conclusión
desarrollo
 Algunas personas necesitan conocer solo los objetivos del negocio,
objetivo
feeback
índice
inicio
otras solo quieren una visión general de alto nivel, otras quieren ver
solo la perspectiva del usuario y otras necesitan todos los detalles.
 No espere que todos sus representantes de usuarios lean el SRS
detallado, y no espere que los desarrolladores aprendan todo lo que
necesitan de un conjunto de casos de uso o historias de usuarios.
12
Estructura del ERS IEEE Std. 830-1998
2. 3.
1. 4.
Introducción Descripción Requisitos
Apéndices
General Específicos
conclusión
desarrollo
objetivo
2.1 Perspectiva del
feeback
3.1 Interfaces
índice
1.1 Propósito
inicio
Producto Externas
2.3 Funciones del

1.2 Ámbito del Producto 3.2 Requisitos de
sistema rendimiento
2.4 Características de
1.3 Definiciones, Usuarios
3.3 Restricciones de
acrónimos y
Diseño
abreviaturas
2.5 Restricciones
3.4 Atributos del

1.4 Referencias
2.6 Suposiciones y Sistema
Dependencias
1.5 Visión General del

2.7 Requisitos Futuros 3.5 Otros requisitos
Documento
13
1.1 Propósito
• En esta subsección se definirá el propósito del documento ERS y

se especificará a quién va dirigido el documento.
conclusión
desarrollo
objetivo
feeback
índice
1.2 Ámbito del Sistema
inicio
• Se podrá dar un nombre al futuro sistema (p.ej. MiSistema)
• Se explicará lo que el sistema hará y lo que no hará.
• Se describirán los beneficios, objetivos y metas que se espera
alcanzar con el futuro sistema.
• Se referenciarán todos aquellos documentos de nivel superior
(p.e. en Ingeniería de Sistemas, que incluyen Hardware y
Software, deberá mantenerse la consistencia con el documento
de especificación de requisitos globales del sistema, si existe).
14
1.3. Definiciones, Acrónimos y Abreviaturas.
• En esta sección se definirán todos los términos,

acrónimos y abreviaturas utilizadas en la ERS.
conclusión
desarrollo
objetivo
feeback
índice
inicio
1.4 Referencias
• En esta sección se mostrará una lista completa de todos

los documentos referenciados en el ERS.
1.5 Visión General del Documento
• Esta subsección describe brevemente los contenidos y la

organización del resto de la ERS.
15
2. Descripción General
• En esta sección se describen todos aquellos factores que afectan al producto y a

sus requisitos. No se describen los requisitos, sino su contexto. Esto permitirá
dedefinir con detalle los requisitos en la sección 3, haciendo que sean más fáciles
de entender.
conclusión
desarrollo
objetivo
feeback
• Normalmente, esta seccion consta de las siguientes subsecciones: Perspectiva del
índice
inicio
producto, funciones del producto, características de los usuarios, restricciones,
factores que se asumen y futuros requisitos.
2.1 Perspectiva del Producto
• Esta subsección debe relacionar el futuro sistema (producto software) con otros
productos. Si el producto es totalmente independiente de otros productos,
también debe especificarse aquí. Si la ERS define un producto que es parte de un
sistema mayor, esta subsección relacionará los requisitos del sistema mayor con
la funcionalidad del producto descrito en la ERS, y se identificarán las interfaces
entre el producto mayor y el producto aquí descrito.
• Se recomienda utilizar diagramas de bloques.
16
2.2 Funciones del producto
• En esta subsección de la ERS se mostrará un resumen, a grandes

rasgos, de las funciones del futuro sistema. Por ejemplo, en una
ERS para un programa de contabilidad, esta subsección mostrará
conclusión
que el sistema soportará el mantenimiento de cuentas, mostrará el
desarrollo
objetivo
feeback
estado de las cuentas y facilitará la facturación, sin mencionar el
índice
inicio
enorme detalle que cada una de estas funciones requiere.
• Las funciones deberán mostrarse de forma organizada, y pueden
utilizarse gráficos, siempre y cuando dichos gráficos reflejen las
relaciones entre funciones y no el diseño del sistema.
2.3 Características de Usuarios
• Esta subsección describirá las características generales de los

usuarios del producto, incluyendo nivel educacional, experiencia y
experiencia técnica.
17
2.4 Restricciones
• Esta subsección describirá aquellas limitaciones que se imponen sobre los

desarrolladores del producto: políticas de la empresa, limitaciones de hardware,
interfaces con otras aplicaciones, operaciones paralelas, funciones de auditoría,
funciones de control, lenguaje de programación, protocolos de comunicación, requisitos
de habilidad, criticabilidad de la aplicación, consideraciones acerca de la seguridad.
conclusión
desarrollo
objetivo
feeback
índice
inicio
2.5 Suposiciones y Dependencias
• Esta subsección de la ERS describirá aquellos factores que, si cambian, pueden afectar a
los requisitos. Por ejemplo, los requisitos pueden presuponer una cierta organización
de ciertas unidades de la empresa, o pueden presuponer que el sistema correrá sobre
cierto sistema operativo. Si cambian dichos detalles en la organización de la empresa, o
si cambian ciertos detalles técnicos, como el sistema operativo, puede ser necesario
revisar y cambiar los requisitos.
2.6 Requisitos futuros
• Esta subsección esbozará futuras mejoras al sistema, que podrán analizar e

implementarse en un futuro.
18
3. Requisitos Específicos
• Esta sección contiene los requisitos a un nivel de detalle su cliente

como para permitir a los diseñadores diseñar un sistema que
satisfaga estos requisitos, y que permita al equipo de pruebas
conclusión
desarrollo
planificar y realizar las pruebas que demuestren si el sistema
objetivo
feeback
satisface, o no, los requisitos. Todo requisito aquí especificado
índice
inicio
describirá comportamientos externos del sistema, perceptibles por
parte de los usuarios, operadores y otros sistemas. Esta es la
sección más larga e importante de la ERS. Deberán aplicarse los
siguientes principios:
• El documento deberá ser perfectamente legible por personas de
muy distintas formaciones e intereses.
• Deberán referenciarse aquellos documentos relevantes que
poseen alguna incongruencia sobre los requisitos.
• Todo requisito deberá ser unívocamente identificable mediante
algún código o sistema de numeración adecuado.
19
3. Requisitos Específicos
• El documento debería ser perfectamente legible por

personas de muy distintas formaciones e intereses.
conclusión
desarrollo
objetivo
feeback
• Deberán referenciarse aquellos documentos relevantes
índice
inicio
que poseen alguna influencia sobre los requisitos.
• Todo requisito debera ser unívocamente identificable
mediante algún código o sistema de numeración
adecuado.
• Lo ideal, aunque en la practica no siempre realizable, es
que los requisitos posean las siguientes características:
Corrección, No ambiguos, Completos, Consistentes,
Clasificados, Verificables, Modificables, Trazables.
20
3.1 Interfaces externas
• Se describirán los requisitos que afecten a la interfaz

de usuario, interfaz con otros sistemas (hardware y
conclusión
desarrollo
software) e interfaces de comunicaciones.
objetivo
feeback
índice
inicio
3.2 Funciones
• Esta subsección (quizá la más larga del documento)

deberá especificar todas aquellas acciones
(funciones) que deberá llevar a cabo el software.
Normalmente (aunque no siempre), son aquellas
acciones expresables como “el sistema deberá….”
21
3.2 Funciones
• Si se considera necesario, podrán utilizarse

notaciones gráficas y tablas, pero siempre
conclusión
desarrollo
objetivo
feeback
supeditadas al lenguaje natural, y no al revés.
índice
inicio
• En paralelo con los DFDs propuestos por el
análisis estructurado.
• Estándar de IEEE 830, en sus últimas versiones, ya
permite organizar esta subsección de múltiples
formas, y sugiere, entre otras, las siguientes: por
tipos de usuarios, por objetos, por objetivos, por
estímulos, por jerarquía funcional.
22
3.2 Funciones
• Por tipos de usuario: Distintos usuarios poseen distintos

requisitos. Para cada clase de usuario que exista en la
organización, se especificarán los requisitos funcionales que le
conclusión
desarrollo
afecten o tengan mayor relación con sus tareas.
objetivo
feeback
índice
inicio
• Por objetos: Los objetos son entidades del mundo real que
serán reflejadas en el sistema. Para cada objeto, se detallarán
sus atributos y sus funciones. Los objetos pueden agruparse en
clases. Esta organización de la ERS no quiere decir que el diseño
del sistema siga el paradigma de Orientación a Objetos.
• Por objetivos: Un objetivo es un servicio que se desea que
ofrezca el sistema y que requiere una determinada entrada para
obtener su resultado. Para cada objetivo o sub-objetivo que se
persiga con el sistema, se detallarán las funciones que permitan
llevarlo a cabo.
23
3.2 Funciones
• Por estímulos: Se especificarán los posibles estímulos que

recibe el sistema y las funciones relacionadas con dicho
estímulo.
conclusión
desarrollo
• Por jerarquía funcional: Si ninguna de las anteriores
objetivo
feeback
índice
inicio
alternativas resulta de ayuda, la funcionalidad del sistema
se especificará como una jerarquía de funciones que
comparten entradas, salidas o datos internos. Se detallarán
las funciones (entrada, proceso, salida) y las sub-funciones
del sistema. Esto no implica que el diseño del sistema deba
realizarse según el paradigma de Diseño Estructurado.
Nota: Para organizar esta subsección de la ERS se elegirá alguna de las

anteriores alternativas, o incluso alguna otra que se considere mas
conveniente. Deberá, eso justifcarse el porque de tal elección.
24
3.3. Requisitos de Rendimiento
• Se detallarán los requisitos relacionados con la carga que se espera tenga

que soportar el sistema. Por ejemplo, el número de terminales, el número
esperado de usuarios simultáneamente conectados, número de
transacciones por segundo que deberá soportar el sistema, etc.
conclusión
desarrollo
• También, si es necesario, se especificarán lo requisitos de datos, es decir,
objetivo
feeback
índice
inicio
aquellos requisitos que afecten a la información que se guardará en la base
de datos. Por ejemplo, la frecuencia de uso, las capacidades de acceso y la
cantidad de registros que se espera almacenar (decenas, cientos, miles o
millones).
3.5. Atributos del Sistema
• Se detallarán los atributos de calidad (las “ilities") del sistema: Fiabilidad,

mantenibilidad, portabilidad, y, muy importante, la seguridad. Deberá
especificarse qué tipos de usuario están autorizados, o no, a realizar ciertas
tareas, y cómo se implementarán los mecanismos de seguridad (por
ejemplo, por medio de un login y una password).
25
3.6. Otros Requisitos
• Cualquier otro requisito que no encaje en otra

sección.
conclusión
desarrollo
objetivo
feeback
índice
inicio
4. Apéndices
• Pueden contener todo tipo de información

relevante para la ERS pero que, propiamente, no
forme parte de la ERS. Por ejemplo: 1) Formatos de
entrada/salida de datos, por pantalla o en listados.
2) Resultados de análisis de costes 3) Restricciones
acerca del lenguaje de programación.
26
conclusión
desarrollo
objetivo
feeback
índice
inicio
Audiencias del Documento de
27
Clientes
El departamento de marketing y
el personal de ventas necesitan Ingenieros de prueba
saber qué producto pueden
esperar recibir.
del sistema
Los probadores lo usan para
conclusión
desarrollar pruebas basadas en
desarrollo
objetivo
feeback
requisitos, planes de prueba y
índice
inicio
Administradores procedimientos de prueba….
Los gerentes de proyecto basan

sus estimaciones de Ingenieros
cronograma, esfuerzo y
recursos en los requisitos….
de mantenimiento
El personal de mantenimiento y
soporte lo utiliza para
comprender lo que se supone
Ingenieros del sistema que debe hacer cada parte del
producto…
Los equipos de desarrollo de
software necesitan saber qué
construir….
28
Redactores
Los redactores de
documentación basan los
manuales de usuario y las
pantallas de ayuda en el SRS y el
diseño de la interfaz de usuario.
conclusión
desarrollo
Personal de
objetivo
feeback
índice
inicio
capacitación Subcontratistas
utiliza el SRS y la documentación Los subcontratistas basan su
del usuario para desarrollar trabajo en, y pueden ser
materiales educativos… legalmente obligados a, los
requisitos especificados….
Personal Legal
se asegura de que los requisitos
cumplan con las leyes y
regulaciones aplicables…
29
Especificación de RQ
Para pensar…
conclusión
desarrollo
objetivo
Si una capacidad o calidad
feeback
índice
inicio
deseada no aparece en algún
lugar del acuerdo de requisitos,
nadie debería esperar que aparezca en el
producto.
30
Use una plantilla apropiada para organizar toda la información

necesaria.
conclusión
desarrollo
Etiquetas y secciones de estilo, subsecciones y requisitos
objetivo
feeback
índice
inicio
individuales consistentemente.
Utilice el énfasis visual (negrita, subrayado, cursiva, color y

fuentes) de manera consistente y juiciosa. Recuerde que el
resaltado de color puede no ser visible para las personas con
daltonismo o cuando se imprime en escala de grises.
Cree una tabla de contenido para ayudar a los lectores a

encontrar la información que necesitan.
Numere todas las figuras y tablas, deles títulos y refiérase a ellas

por número.
31
Si está almacenando requisitos en un documento, defina el

recurso de referencia cruzada de su procesador de textos en
lugar de números de página o sección codificados para referirse a
conclusión
desarrollo
otras ubicaciones dentro de un documento.
objetivo
feeback
índice
inicio
Si está utilizando documentos, defina hipervínculos para permitir
al lector saltar a secciones relacionadas en el SRS o en otros
archivos.
Si está almacenando requisitos en una herramienta, use enlaces
para permitir que el lector navegue a la información relacionada.

Contrate a un editor experto para asegurarse de que el

documento sea coherente y utilice un vocabulario y un diseño
coherentes
32
Etiquetado de requisitos
Cada requisito necesita un identificador único y persistente.

permite referirse a requisitos específicos en una solicitud de
cambio, historial de modificaciones, referencias cruzadas o matriz
de trazabilidad de requisitos.
conclusión
desarrollo
Permite reutilizar los requisitos en múltiples proyectos.
objetivo
feeback
índice
inicio
Requisitos identificados de forma única facilitan la colaboración
entre los miembros del equipo cuando discuten los requisitos,
como en una reunión de revisión por pares.

Las listas simples numeradas o con viñetas no son adecuadas

para estos fines.
33
Secuencia de números
El enfoque más simple proporciona a cada requisito un número

de secuencia único, como UC-9 o FR-26
El prefijo indica el tipo de requisito, como FR para el requisito

funcional.
conclusión
desarrollo
objetivo
feeback
índice
inicio
Enfoque de numeración simple no proporciona ningún grupo

lógico o jerárquico de requisitos relacionados, el número no
implica ningún tipo de orden y las etiquetas.
Facilita la retención de un identificador único si mueve los

requisitos en un documento.
34
Numeración jerárquica
Si los requisitos funcionales aparecen en la sección 3.2 de su SRS,

todos tendrán etiquetas que comienzan con 3.2.
Más dígitos indican un requisito de nivel inferior más detallado,

por lo que sabe que 3.2.4.3 es un requisito secundario de 3.2.4
conclusión
desarrollo
objetivo
feeback
índice
inicio
Si inserta un nuevo requisito, los números de los siguientes

requisitos en esa sección se incrementarán.
Eliminar, insertar, fusionar o mover secciones enteras, y muchas

etiquetas cambian. Estos cambios interrumpen cualquier
referencia a esos requisitos en otras partes del sistema.
35
Etiquetas textuales jerárquicas
El consultor Tom Gilb (1988) sugiere un esquema de etiquetado
jerárquico basado en texto para etiquetar los requisitos
individuales.
Considere este requisito: "El sistema le pedirá al usuario que

conclusión
desarrollo
objetivo
feeback
confirme cualquier solicitud para imprimir más de 10 copias". Este
índice
inicio
requisito podría estar etiquetado como:
Print.ConfirmCopies.
Esto indica que es parte de la función de impresión y se relaciona con

el número de copias para imprimir.
36
conclusión
feeback Etiquetas textuales jerárquicas
desarrollo
inicio
índice
37
objetivo
Interfaces de usuario
La incorporación de diseños
de interfaz de usuario en el
SRS tiene ventajas y
desventajas. En el lado
conclusión
desarrollo
positivo, explorar posibles
objetivo
feeback
índice
inicio
interfaces de usuario con
prototipos en papel,
maquetas de trabajo,
estructuras alámbricas o
herramientas de simulación
hace que los requisitos sean
tangibles tanto para los
usuarios como para los
desarrolladores.
38
conclusión
desarrollo
feedback
objetivo
índice
inicio
Plantilla especificación de
39
Plantilla ERS
conclusión
desarrollo
objetivo
feeback
índice
inicio
Fuente: Ver estructura estándar
40
Ejemplo ERS
conclusión
desarrollo
objetivo
feeback
índice
inicio
Fuente: Ver estructura ejemplo
41
El resultado del desarrollo de requisitos es un acuerdo documentado entre las partes
conclusión
desarrollo
feedback
interesadas sobre el producto a construir. Como viste en capítulos anteriores, el
objetivo
índice
inicio
documento de visión y alcance contiene los requisitos comerciales, y los requisitos
del usuario se pueden capturar en forma de casos de uso o historias de usuarios.
Los requisitos funcionales y no funcionales del producto a menudo se almacenan en
una especificación de requisitos de software, o SRS, que se entrega a aquellos que
deben diseñar, construir y verificar la solución. El registro de los requisitos de manera
organizada que las partes interesadas clave del proyecto pueden revisar ayuda a
garantizar que sepan lo que están aceptando.
42

MÉXICO.
bibliografía
conclusión
desarrollo
feedback
objetivo
índice
inicio
4. VEGA, M. CASOS DE USO UML, UNIVERSIDAD DE GRANADA.

5. KARL W. & JOY B., (2013). SOFTWARE REQUERIMENTS, THIRD EDITION, MICROSOFT.
43

Requerimiento para TEST3

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

Requerimiento para TEST3

Cargado por

Copyright:

Formatos disponibles

Ingeniería de

UNIDAD 3: Especificación requerimientos de

TEMA 1: Documentación básica de requisitos

Ing. Jorge Vinueza Martínez, Mgs.

Modelo del Arquitectura

 SUBTEMA 1: Estructura del ERS (introducción, objetivos, características,

esquema, Perspectiva del producto)

Especificar la documentación básica de los

requerimientos de software concebidos en

Fuente: IEEE (2014). Guide to the Software Engineering body of

Algunas organizaciones grandes,

La especificación de requisitos de software tiene muchos nombres en

desarrollar pruebas basadas en

requisitos, planes de prueba y

Los gerentes de proyecto basan

Fuente: Gerald Kotonya sobre ingeniería de requerimientos (Kotonya y Sommerville, 1998)

Fuente: Gerald Kotonya sobre ingeniería de requerimientos (Kotonya y Sommerville, 1998)

Fuente: Gerald Kotonya sobre ingeniería de requerimientos (Kotonya y Sommerville, 1998)

La mayoría de los proyectos crearán solo una especificación de

Caso de estudio - ¿Cuánta especificación?

Use una plantilla apropiada para organizar toda la información

Utilice el énfasis visual (negrita, subrayado, cursiva, color y

Cree una tabla de contenido para ayudar a los lectores a

Numere todas las figuras y tablas, deles títulos y refiérase a ellas

Si está almacenando requisitos en un documento, defina el

Incluya representaciones visuales de información cuando sea

Contrate a un editor experto para asegurarse de que el

Cada requisito necesita un identificador único y persistente.

Incluya representaciones visuales de información cuando sea

Las listas simples numeradas o con viñetas no son adecuadas

El enfoque más simple proporciona a cada requisito un número

El prefijo indica el tipo de requisito, como FR para el requisito

Enfoque de numeración simple no proporciona ningún grupo

Facilita la retención de un identificador único si mueve los

Si los requisitos funcionales aparecen en la sección 3.2 de su SRS,

Más dígitos indican un requisito de nivel inferior más detallado,

Si inserta un nuevo requisito, los números de los siguientes

Eliminar, insertar, fusionar o mover secciones enteras, y muchas

Considere este requisito: "El sistema le pedirá al usuario que

confirme cualquier solicitud para imprimir más de 10 copias". Este

Esto indica que es parte de la función de impresión y se relaciona con

Fuente: Ver estructura estándar

Fuente: Ver estructura ejemplo

(Karl Wiegers & Joy Beatyy, 2013)

1. PRESSMAN, ROGER S. (2010). INGENIERÍA DEL SOFTWARE. MEXICO: MCGRAW-HILL.

4. VEGA, M. CASOS DE USO UML, UNIVERSIDAD DE GRANADA.

UNIDAD 3: Especificación requerimientos de

TEMA 2: Técnicas de especificación de

Ing. Jorge Vinueza Martínez, Mgs.

Modelo del Arquitectura

 SUBTEMA 1: Documentación de requisitos impulsados por el plan.

 SUBTEMA 2-3: Historias de usuarios.

las etapas obtención de requisitos mediante

técnicas de análisis y negociación para

Robertson y Robertson 1994

Fuente: Karl Wiegers & Joy Beatyy, 2013

El "sistema" dentro del

Figura 5-6: Diagrama contextual parcial del Sistema de seguimiento de

Una lista de eventos

sistema. La lista de eventos

Diagrama de Flujo de Datos (DFD)

Qué son las siglas DFD?

En síntesis, el diagrama de flujo de datos describe: