Análisis de Requerimientos

Instituto
ISP Superior
Pascal
TDS - Tecnicatura en Desarrollo de Software

Análisis de Requerimientos - tercer cuatrimestre
índice
presentación 3
objetivos 4

programa 4

material 6
clases
clase 1 | 7
clase 2 | 23
clase 3 | 38
clase 4 | 46
clase 5 | 52
clase 6 | 61
clase 7 | 65
clase 8 | 84
clase 9 | 103
clase 10 | 113
clase 11 | 135
clase 12 | 138

evaluación integradora 146
impresión total del documento ! 146 páginas
ISP | Análisis de Requerimientos| Tercer Cuatrimestre 2

presentación Bienvenido a la materia ‘Análisis de Requerimientos’.
Para introducirlo en este mundo primero es necesario definir dos conceptos:

análisis y requerimiento. Dado que luego lo vamos a profundizar durante el
cursado menciones definiciones básicas.
• Análisis, aunque sería mucho mejor expresarlo como un verbo dado

que es una acción: ‘Analizar’ consiste en examinar una cosa separando
las partes que lo constituyen y preguntarse sobre sus características,
cualidades o estados.
• ´Requerimiento’ petición de algo que se considera necesario.
Entonces al combinar estos dos conceptos dejamos un poco más clara la idea,
el ‘Análisis de Requerimiento’ consiste en desmenuzar los requisitos que nos
plantearon los clientes y otros interesados sobre el software a construir.
Pero, nos falta una pata previa, el relevamiento. El concepto de relevamiento es

una revisión, una investigación o un estudio de algo. Lo que se hace al relevar,
en este sentido, es registrar cierta información que se detecta a partir de una
observación. Esta detección por medio de la observación se asocia también al
descubrimiento, y... ¿cuál es la diferencia entre observar y descubrir? Descubrir
implica una acción de nuestra parte como “opuesto a observar”, implica que
estemos pasivos.
En esta materia vamos a estudiar cómo relevar y analizar los requisitos de

los usuarios y otros interesados que desean un desarrollo de un software.
Es entender qué se desea o necesita, a ese qué se debe dejarlo expresado
de alguna manera que todas las partes hablen el mismo lenguaje y facilite la
comprensión mutua.
Esta expresión ‘de alguna manera’ es lo que ubica a esta materia dentro del
programa de la tecnicatura. Para comenzar el desarrollo debemos primero saber
QUE debemos programar. Para comenzar a desarrollar debemos primero saber
COMO hacer para saber QUE debemos programar.
El relevamiento, análisis y especificación de los requisitos de los usuarios es

conocido como “Ingeniería de Requisitos”. Y es uno de los puntos más críticos y
más difíciles de llevar adelante en un proceso de desarrollo. ¿Por qué?
La respuesta es simple, es muy difícil que el usuario y los interesados sepan con
exactitud lo que quieren y que hayan pensado todas las alternativas posibles.
Es más no solo están los variados usuarios que puede tener un sistema, cada
uno con su visión diferente sino que existen otros interesados, el cliente que
pone el dinero para el desarrollo, las políticas de la organización, las leyes de
la región, y otra gran variedad, y muy posiblemente los requisitos apunten a
distintos objetivos: el dueño de la empresa va querer que el software salga lo
menos posible y por lo tanto su funcionalidad va a ser la mínima indispensable,
pero el usuario final va a querer que su funcionalidad sea la máxima posible que
simplifique su trabajo.

¿Y cómo logramos esto? Pues, la respuesta está en las clases.
Les cuento cómo organizaremos las clases: las dos primeras nos van a introducir
en el concepto de requerimiento, la clasificación de los mismos y la importancia.
Luego, en las clases 3, 4 y 5 continuaremos con las técnicas de relevamiento.
Las clases 6, 7 y 8 las vamos a dedicar al análisis y modelado. Luego vamos
a aprender a informar sobre los requerimientos, para su validación para dar a
conocer su estado. Finalmente, la última clase será para unir todo lo que vimos
en un proceso integral de gestión de requerimientos que puede ser utilizado
dentro de un modelo de desarrollo.
¡Adelante!
objetivos
• Comprender y valorar los requerimientos y su importancia con el fin de
conocerlos y que sean base de las técnicas.
• Conocer y aplicar las distintas técnicas de relevamiento, análisis y
verificación de los requerimientos con el fin de aplicarlas en el ejercicio
de la profesión.
• Desarrollar un proceso de gestión de los requerimientos y de sus cambios
con el fin de aplicarlo en el ejercicio de la profesión y comprometer al
resto del equipo de desarrollo en su uso.
programa
Módulo 1: Introducción y Panorama General
• Desarrollado en las clases 1 y 2
Objetivos específicos
- Comprender el concepto de requerimiento y los distintos tipos de los mismos a
fin de tener una base firme del dominio del problema.
- Conocer la importancia de los requerimientos para poder determinar su

impacto en el desarrollo y la calidad del software.
Contenidos
Concepto de Requisitos. Clasificación de los Requisitos. Requisitos del Dominio.
La importancia de los Requisitos.
Módulo 2: Relevamiento y Análisis de la información

• Desarrollado en las clases 3, 4 y 5
- Incorporar las distintas técnicas de relevamiento de los requisitos para
poder ponerlas en práctica y descubrir los requisitos de los interesados.
- Discernir cuando utilizar cada una.
Contenidos
Los interesados. Las técnicas. Entrevistas. Prototipos. Escenarios. Reuniones
Moderadas. Puntos de vistas y Observación.

Módulo 3: Modelado y Análisis de la información
• Desarrollado en las clases 6, 7 y 8
- Incorporar las distintas técnicas para modelar los requisitos en un lenguaje
común entre las partes y en un lenguaje técnico de cara al desarrollo para
ponerlas en práctica y lograr los acuerdos necesarios entre las partes
interesadas en el desarrollo del software.
Contenidos
La especificación. Std. IEEE830. Casos de Uso. Mapas Mentales. Validación de
los Requisitos. Requisitos duraderos y volátiles.
Módulo 4: Uniendo las partes e Informando los Requerimientos

- Comprender la utilidad de un documento de especificación de
requerimientos como una formalidad del proceso de desarrollo para
poder darle la importancia que requiere cuando se realiza un trabajo
profesionalmente.
- Aprender las partes de un informe de requerimientos con el fin de poder
armarlos.
- Conocer los métodos de especificación formal de software, sus ventajas
y desventajas.
Contenidos
Unir los relevamientos en un solo documento - Ampliando el Std. IEEE 830 –
Especificaciones Formales – Notación Z.
Módulo 5: El proceso de Gestión de los Requerimientos

- Conocer porque es necesaria la gestión de los requerimientos y sus pasos
principales para poder incorporarla dentro de un proyecto de software.
- Comprender que es necesario gestionar los cambios a los requerimientos.
Contenidos
Los pasos del Proceso de Requerimientos – Gestión de Cambios de los
Requerimientos - El perfil del Ingeniero de Requerimiento – Separación de
Problemas y Soluciones.

bibliografía Material básico:
• Sommerville, Ian (2011): Ingeniería de Software. 9° Edición. Pearson

educación. Link web (en inglés): http://www.SoftwareEngineering-9.com/
Material complementario:
• A lo largo de la asignatura se indican páginas web para realizar lecturas

complementarias.

clases
clase 1 QUÉ ES UN REQUERIMIENTO DE SOFTWARE Y LOS DISTINTOS TIPOS

introducción
Lo que buscamos en esta primera clase es introducirlo en el mundo de la Ingeniería

de Requerimientos. Los requerimientos son un tema sensible del desarrollo de
software, sobre todo si lo que se pretende desarrollar no es un software trivial. Se
presupone siempre que el cliente sabe exactamente lo que desea, pero no es así.
Hay un gran rango que va desde aquellos que tienen 100% definida la idea del
software a aquellos que sólo tienen una vaga noción. Siendo este último extremo
el más habitual.
Los requerimientos son descripciones de lo que los interesados esperan que

haga el sistema. Esta descripción puede ser tan vaga como ‘facturar mis ventas’
a algo más complejo como la descripción de los comprobantes a emitir junto con
su diseño, las distintas alternativas de cálculos, los datos de las GUI, y otros más.
El desafío de los requisitos es conseguirlos y que se acerquen al extremo de lo

más detallado posible sin llegar a ser algo inmanejable e incomprensible para la
mente de las personas.
También repasamos en el 2° tema de la clase la distinción entre Requerimiento

y Requisito.
clase 1
El Concepto de Requerimiento.
tema 1
Los requerimientos son descripciones de aquello que los clientes solicitan que el
sistema/software haga y de las restricciones a cumplir mientras lo hace. Pueden
ser muy vagas o muy completas, hay una gran variedad. Cuanto más completas,
menos probabilidades de retrabajo habrá al construir sistema. Cuanto más vagas,
por el contrario, habrá más probabilidades de rehacer el sistema. A su vez, cuanto
más completos los requerimientos más certeras serán las estimaciones y mayores
las probabilidades de cumplirlas, y al revés, cuanto más vagas las estimaciones
menos posibilidades tendrán de ser ciertas.
La obtención de los requerimientos es complicada, los usuarios no siempre

saben lo que quieren individualmente y colectivamente es muy frecuente que
nos planteen necesidades contradictorias. Luego aquí ya descubrimos que hay
un proceso de negociación y de filtro. Y luego de especificarlos de forma precisa.

No sólo debemos considerar, dentro del colectivo del cual obtenemos los
requisitos, a los usuarios. Ellos son una parte fundamental, pero solo una parte.
Debemos considerar a los demás interesados: al dueño de la empresa, a los
vecinos, a las otras áreas de la empresa, a la prensa, a los organismos estatales,
la lista puede ser larga.
Debemos también tener en cuenta que los requisitos no son fijos, cambian con el
tiempo, incluso durante el mismo período de desarrollo del software.
¿Y cómo se ve un requisito?
Los clientes pueden participar del programa de Millaje. El canje

de millas implica que puede obtener pesos de descuento para
adquirir, hasta cierto tope, pasajes.
Este requisito es un requisito vago, muy orientado al usuario, y poco orientado al

desarrollador y al testeador del software.
Quien releva los requisitos suele ser una persona que cumple el rol de ‘analista
de sistemas´. Un analista es alguien capaz de analizar y de descomponer un todo
en partes y encontrar las relaciones entre ellas. En la frase anterior mencionamos
‘un todo’, y justamente ese ‘todo’ es el punto de partida de las especificaciones.
Releamos la especificación anterior, ¿Cuál es el todo? Algo podemos ‘Suponer’:

está hablando de un sistema de ventas de pasaje de una aerolínea y que tiene un
programa de millaje, donde pueden cambiarse las millas acumuladas por pesos
de descuento para usar en compras de nuevos pasajes.
Atención, ¿la ‘suposición’ parece correcta no? Sí, puede serlo, pero puede que
no. Es fundamental que al relevar requerimientos NO SE SUPONGA, sino que
todo se averigüe y se confirme. Si suponemos, el supuesto debe ser corroborado.
Los clientes pueden participar del programa de Millaje. El canje

de millas implica que puede obtener pesos de descuento para
adquirir, hasta cierto tope, pasajes en nuestros trenes.
No, no eran aviones, eran trenes. No debemos suponer acerca de ese ‘todo’
del cual parten los requerimientos (o requisitos). Debemos verlo todo, debemos
escucharlo todo, debemos comprenderlo todo, para poder luego especificarlo en
un nivel de detalle suficiente para el desarrollo.

Los clientes, categoría “gold label” pueden participar de programas
de Millaje. El canje de millas implica que puede obtener pesos de
descuento para adquirir, hasta cierto tope, pasajes en nuestros
trenes.
Indagando, analizando, se puede llegar a un requisito más detallado:
Los clientes, categoría “gold label” pueden participar de

programas de Millaje. El canje de millas implica que puede
obtener hasta $1000 de descuento para adquirir, hasta cierto
tope, el 40% del valor del mismo, pasajes en nuestros trenes,
pero sólo para aquellos servicios durante los días laborables.
Los servicios de los ferrocarriles durante un fin de semana o
feriado no estarán disponibles.
Excelente, el requerimiento se ha ido detallando; el analista finalizó su trabajo con

el cliente que solicitó el sistema, el jefe del área de boleterías. Ahora pidió hablar
con un “boletero” quien va a usar el sistema en su trabajo diario.

pero solo para aquellos servicios durante los días laborables.
feriado no estarán disponibles. Al momento de adquirir el pasaje
el cliente debe presentar el voucher que le emitió la web de
la compañía al realizar el canje, de ese voucher tenemos que
anotar su número. Y ese monto de pesos canjeados debe tener
discriminado el IVA, que ya lo tiene incluido, al emitir la factura
por la compra del pasaje.
Aparecieron aquí dos requisitos del usuario final. El analista continua su recorrido

comprendiendo este requerimiento pero desde el lado de vista del gerente de
finanzas.

anotar su número. El monto total de los canjes no debe superar
el 25% de las ganancias brutas mensuales sino los flujos de
cajas se complicarían de gran manera afectando la liquidez de
la empresa necesaria para operar.
Y luego, el analista pasa por el sector de atención de reclamos de Servicio al

Cliente:

anotar su número. El monto total de los canjes no debe superar
el 25% de las ganancias brutas mensuales sino los flujos de
cajas se complicarían de gran manera afectando la liquidez de
la empresa necesaria para operar. Es necesario que boletero
fotocopie o retenga, adjunto a una copia del pasaje, el voucher
de canje del cliente y una fotocopia de su documento como
prueba de que validó su identidad ante un eventual reclamo.
¿Qué sucedió aquí? Se fue detallando el requerimiento al ir descubriendo y

sumando a los interesados en el sistema. A su vez esto nos va permitiendo conocer
y comprender el “Dominio del Software”. Los analistas y los desarrolladores sí
o sí deben tener conocimientos de informática, de sistemas, de lenguajes de
programación, de herramientas de modelados. Pero no necesariamente van a
tener conocimientos del negocio que va a ser soportado por el software. Es

fundamental que lo comprenda para poder comprender los requisitos.
El ‘todo’ antes mencionado es este dominio del software

o dominio del problema o contexto del sistema debe
especificarse, de ser posible, como un modelo, al que
todos acceden y brinde a todos la misma visión y el mismo
vocabulario de los objetos que lo componen, para que
Atención
“todos hablemos de lo mismo y no nos confundamos”,
léase todos como la suma de los participantes del
desarrollo del software más los interesados.
Los requisitos como habremos observado hasta aquí pueden ser tan complejos
como queramos o necesitemos o así se imponga. Un requisito vago, como
el primero de la serie anterior no es un mal requisito, no es el ideal, pero es
suficiente para comenzar a desarrollar. Durante el desarrollo mismo, el testing o
el uso en producción surgirán las preguntas que nos llevarán a detallar cada vez
el requerimiento hasta llegar a la versión más avanzada. Sólo que en estos casos
va a implicar modificaciones a un soft existente e incluso en producción.
Conclusión: cuanto antes en el ciclo de vida del software y cuanto más detallado,
mejor.
Llegados a este punto ya tenemos en nuestras mentes el concepto de requisito

o requerimiento de software. El próximo tema será clasificarlo, para poder
ordenarlos en nuestras mentes y nuestras especificaciones. Clasificamos porque
somos humanos.
Para ampliar el contenido de este capítulo sugiero leer del

libro que conforma la bibliografía básica:
Leer Sommerville, Ian. Ingeniería de Software 9° Edición.
Pearson Educación. México. 2011. - Capítulo 4 – Ingeniería
de Requerimientos. Introducción previa al apartado 4.1
Actividad 1: Comencemos a trabajar en los requisitos

En esta actividad le solicitamos: Detallar aún más el requisito
anterior.
Actividad
Imaginemos que nos pueden pedir acerca del mismo los
siguientes roles de la empresa:

• El comercial que vende boletos “al por mayor” a clientes
corporativos y está interesado en vender para cobrar su
comisión.
• El comisario de a bordo.
• Los auditores que deben verificar que el proceso de uso de
los descuento sea correcto.
¡Adelante!
clase 1 Clasificación de los requerimientos
tema 2
Primero vamos a distinguir dos conceptos que por lo general se utilizan como
sinónimos: Requisitos y Requerimientos.
Según la RAE, “Requerimiento” es un sinónimo de necesidad, es decir, un concepto

orientado hacia la carencia o falta de algo y al hecho de plantear esa necesidad
o carencia, orientado a la acción. “Requisito” es, en cambio, una circunstancia
o condición necesaria para algo. Convengamos entonces que los Requisitos
serían el conjunto de condiciones que el software debe cumplir (funcionalidades,
características y restricciones). Y convengamos que los Requerimientos son
todos los pedidos, los planteos de necesidades y deseos, llevados a cabo por los
clientes e interesados en el software.
Si nos atenemos a la norma IEEE 830 Std. La palabra correcta a utilizar es Requisito.
Ahora, a los fines prácticos y dentro del contexto donde nos desenvolvemos,
podemos utilizar estos términos de manera intercambiable, pero, a los fines de
este curso vamos a distinguirlos.
Avancemos, para entender los humanos clasificamos, clasifiquemos entonces,

los requisitos.
Los requisitos tienen muchas clasificaciones, con categoría no excluyentes entre

las distintas clasificaciones. Veamos:

• Requisitos Funcionales
• Requisitos No-Funcionales
• Requisitos del Usuario

• Requisitos del Sistema
• Requerimientos del producto

• Requerimientos de la organización
• Requerimientos externos

1- Requisitos Funcionales y No-Funcionales:
Requisitos Funcionales: Son enunciados acerca de servicios que el sistema

debe proveer, de cómo debería reaccionar el sistema a entradas particulares y
de cómo debería comportarse el sistema en situaciones específicas. En algunos
casos, los requerimientos funcionales también explican lo que no debe hacer el
sistema. (Tomado de Ing. de Software 9° ed. Ian, Sommerville)
Requisitos No-Funcionales: Son limitaciones sobre servicios o funciones que

ofrece el sistema. Incluyen restricciones tanto de temporización y del proceso de
desarrollo, como impuestas por los estándares. Los requerimientos no funcionales
se suelen aplicar al sistema como un todo, más que a características o a servicios
individuales del sistema. (Tomado de Ing. de Software 9° ed. Ian, Sommerville)
2- Requisitos del Usuario y del Sistema:
Requisitos del usuario: “son enunciados, en un lenguaje natural junto con

diagramas, acerca de qué servicios esperan los usuarios del sistema, y de las
restricciones con las cuales éste debe operar” (tomado de Ing. de Software 9°
ed. Ian, Sommerville)
Requisitos del sistema: “son descripciones más detalladas de las funciones, los
servicios y las restricciones operacionales del sistema de software. El documento
de requerimientos del sistema (llamado en ocasiones especificación funcional)
tiene que definir con exactitud lo que se implementará. Puede formar parte del
contrato entre el comprador del sistema y los desarrolladores del software”.
(Tomado de Ing. de Software 9° ed. Ian, Sommerville)
Entonces, son dos puntos de vista del mismo pedido, el del usuario a muy alto
nivel y el del sistema más detallado. Veamos un ejemplo:
Req. del Usuario: al final del día necesitamos un listado que nos permita hacer el
cierre de las cajas.

Req. del Sistema: al final del día, después que se cierran las cajas para atender
al público, se debe emitir, solo por parte del rol supervisor o gerente, un listado
con todas las cobranzas del día. Este listado debe estar ordenado por: caja en 1°
lugar, luego por cajero y por hora indicando cada una de las cobranzas y a qué
venta corresponden. Cada cobranza debe detallar los medios de pago, efvo./
débito/crédito. Al finalizar el reporte debe haber un total del monto de cada caja
por cada medio de pago. Luego se debe emitir una hoja más donde el supervisor
de caja y los cajeros firman aceptando el recuento de los pagos y un espacio para
que el tesorero lo acepte como rendición.
¿Diferencia? El nivel de detalle es lo primero que observamos y después, el

requisito del sistema nos sirve para validar lo desarrollado.
Actividad 2: Descubrir los Requisitos Funcionales y los

No-Funcionales
Actividad
1- Lea detenidamente el siguiente texto y si es necesario
reléalo.
2- Descubra en él un requerimiento funcional y
expréselo como requerimiento de usuario.
3- Luego descubra un requerimiento no funcional.
Trabajamos en el área de sistemas de una gran empresa dedica al retail.

Recientemente hemos recibido el llamado del supervisor de líneas de caja que
nos ha expresado su preocupación, y nos ha contado que en una reciente
auditoria le han observado que no puede informar, como lo expresa el
procedimiento, el monto cobrado por cada forma de pago, por cada uno de los
rubros de artículos que vende la cadena de retail.
De acuerdo al procedimiento esta información debe quedar disponible en el
área de finanzas al cierre de cada día laborable. Esta disponibilización debe
hacerse vial e-mail o mediante un upload a algún sitio y debe ser una tarea que
implique poco y nada de tiempo al supervisor de cajas ya que no aporta valor
alguno, debe ser un proceso muy fácil de usar.

Ampliación de los Requisitos No Funcionales.
Los requisitos no funcionales, a su vez, pueden clasificarse en “Requisitos del

Producto”, “Requisitos de la Organización” y “Requisitos Externos”.
Los “requisitos del producto” son los que especifican o restringen el comportamiento
del software. Por ejemplo: rendimiento, cantidad de memoria, tasa de fallas
máxima, requisitos de usabilidad.
Los “requisitos de la organización” son aquellos derivados de las políticas y

procedimiento del cliente y del desarrollador. Por ejemplo: el sistema debe ser
accedido desde tal navegador de Internet y en tal versión dada que es la única
versión que se dispone.
Los “requisitos externos” son todos aquellos derivados de factores externos al

cliente y a su proceso de desarrollo. Por ejemplo: los impuestos deben calcularse,
en el módulo de ventas, de acuerdo a las normas de la AFIP.
Para ampliar el contenido de este tema, lea el siguiente

apartado de la bibliografía básica:
de Requerimientos. Apartado 4.1

clase 1
Actividad 1: Comencemos a trabajar en los requisitos
claves de corrección
Una posibilidad es ampliar la descripción del requisito refiriéndose a la labor del
comercial, luego de preguntar a su jefe cuáles son las limitaciones y características
del mismo:
Luego por el lado del comisario de a bordo:

Y para los auditores internos de la empresa:
Actividad 2: Descubrir los Requisitos Funcionales y los No-Funcionales
Requisito Funcional: informar, como lo expresa el procedimiento, el monto

cobrado por cada forma de pago por cada uno de los rubros de artículos que
vende la cadena de retail.
Requisito No Funcional: disponibilizar esta información a finanzas debe ser un

proceso muy fácil de usar.

clase 1
conclusiones Lo que hemos visto hasta el momento nos permite comprender qué es un
requisito, entender desde dónde se obtienen y clasificarlos para su mejor gestión.
A su vez, diferenciamos Requerimientos de Requisitos, aunque en la práctica se
usan como palabras intercambiables.
Finalmente, comprendamos que los requisitos son fundamentales, ya que son

ellos los que indican al desarrollador quede hacer (no cómo programar, sino qué
funcionalidad desarrollar y cómo). Son la base del software.

clase 2 PROFUNDIZAR EL ENTENDIMIENTO Y COMPRENDER LA IMPORTANCIA
introducción DE LOS REQUERIMIENTOS.
Primeramente vamos a conocer los requerimientos del dominio y su importancia.

Luego vamos a analizar la importancia de los requerimientos funcionales y como
la consideramos dentro de las metodologías ágiles. Finalmente la importancia de
los requerimientos no funcionales.
Y ¿Por qué son importantes los requerimientos? No sólo porque son la indicación
de lo que se debe desarrollar, sino porque serán la medida con la cual obtendremos
el OK del trabajo.
clase 2 Requerimientos del Dominio.

tema 1
El sistema a desarrollar a partir de los requerimientos

deberá interactuar con su entorno. Es decir, no va a ser
Atención utilizado aisladamente.
Pero, ¿que entendemos por entorno de una aplicación? O expresado de otra

manera, su DOMINIO.
Comencemos entendiendo la palabra “dominio” que tiene muchos significados

distintos según la rema del conocimiento. Lo mejor es asimilarlo al concepto de
Territorio observado como:
“Desde la tradición espacial, el territorio se entiende como un sistema espacial,

es decir, como un conjunto de lugares interconectados por redes y flujos
horizontales. También puede usarse como sinónimo de espacio absoluto
sobre el que los distintos objetos y fenómenos se depositan”
“Desde la tradición social, el territorio se entiende como el sistema socioecológico

que reúne la sociedad y el medio que ésta habita. El territorio se estudia tanto
en sus relaciones verticales (entre sociedad y medio físico), como en sus
características (organización económica, política, demográfica, espacio
construido, medio físico en cuanto condiciona a la sociedad, etc.) como en sus
relaciones horizontales (entre los diversos subterritorios que lo conforman)”
Fuente: Ambos conceptos tomados desde Wikipedia: https://es.wikipedia.org/

wiki/Territorio)

Es importante tener presente lo remarcado en negrita, el
Dominio de un software es el territorio donde el mismo
habita y donde existen distintos objetos y fenómenos
Atención y los mismos se relacionan entre sí y poseen ciertas
características.
Es necesario, para capturar los requisitos correctos y construir el sistema correcto;

conocer y entender este Dominio (contexto o entorno del software). Del dominio
tomamos, entonces, conceptos claves y el vocabulario del mismo.
Repetimos que hay tres puntos importantes:

- Conocer el dominio para poder asegurarnos
de levantar los requisitos funcionales y no
funcionales correctamente.
- Levantar del dominio mismo requisitos
Atención necesarios para el software.
- Conseguir un glosario de términos a partir del
cual se promueva el entendimiento entre las
partes (todos hablan el mismo lenguaje).
Los requerimientos del dominio se expresan usando terminología propia del

mismo. Los requerimientos del dominio son muy importantes dado que forman
las bases de la aplicación.
Si los requerimientos del dominio no son correctamente satisfechos es

muy difícil que el sistema funcione correctamente
Ejemplo:
Supongamos un Sistema de liquidación de impuestos, por ejemplo SIAP,
el proporcionado por AFIP. Hay conceptos del dominio que deben estar aquí
representados como base para poder levantar los requisitos:
- Impuesto
- Contribuyente
- Calendario de vencimientos
- Bien patrimonial
- Ganancia
- Ingresos Brutos
- Alícuota
- Base imponible
- …

Es una buena práctica para conocer el dominio de una aplicación realizar un
modelo del mismo y un glosario.
Existen distintas técnicas:
- Diagramas BPMN de los procesos

- Diagramas de clases o de casos de uso
- Mapas mentales de los conceptos y sus relaciones
Agregamos algunos links donde pueden ampliar los

conocimientos en estas técnicas:
BPMN: https://es.wikipedia.org/wiki/Business_Process_
Model_and_Notation
Mapa Mental: https://es.wikipedia.org/wiki/Mapa_mental
El modelo y el glosario deben estar permanente a disposición de

los participantes del desarrollo de software y a su vez deben estar
permanentemente expuesto a revisión.
Para ampliar el contenido de este tema lea el siguiente

apartado:
Leer
Sommerville, Ian. Ingeniería de Software 9° Edición.
de Requerimientos. Apartados 4.1.1. Link Web: http://
www.SoftwareEngineering-9.com/Web/Requirements/
DomainReq.html
El próximo paso que vamos a dar es bajar estos conceptos a tierra realizando
una actividad práctica:
Actividad 1: Componentes del dominio de un sistema
de facturación
Actividad Supongamos que hemos sido contratados para desarrollar

un sistema de facturación para un restaurante. Dado que el
dominio del mismo es algo conocido por todos lo tomaremos
como base para esta actividad.

A partir del planteo de dos requisitos:
A- identifique que conceptos pertenecen al dominio y
B- enumérelos a continuación agregándole a cada uno una breve definición
(por muy obvia que pueda parecer).
Req. 1 – Todos los platos, bebidas, postres y adicionales solicitados por un

grupo de comensales pueden ser facturados unidos o por separados.
Req. 2 – Ciertos platos, bebidas, postras y adicionales pueden tener asociado

un beneficio (un descuento) de acuerdo al horario en que fueron solicitados. Si
la permanencia del grupo de comensales se extiende más allá del horario fijado
para la promoción lo mismo se les otorgara el descuento dado que el horario de
apertura de la mesa fue dentro del horario de la promo.
C- Responda luego la pregunta y justifíquela:
¿Considera Ud. que la enumeración de estos términos y, sobre todo especificar

un significado a los mismos, le ayudó a la comprensión de los requisitos?
clase 2 La importancia de los Requerimientos

tema 2
En el tema 1 de esta clase vimos la importancia de los Requisitos del Dominio,
no sólo como base para el desarrollo, sino también como glosario para el
entendimiento entre los participantes. Ahora bien, los requisitos funcionales
definen los servicios específicos que debe proporcionar el software. La inexactitud
en los mismos causa muchos problemas. Una de las principales causas es el
nivel de detalle. La falta de exactitud puede causar que los requisitos tengan
interpretaciones ambiguas entre las partes.
Es muy probable que los desarrolladores tiendan a interpretarlo de forma tal

que la implementación sea más simple. Lo que no necesariamente es el deseo
del cliente. Lo mismo, el cliente no siempre está seguro de lo que necesita ni
tampoco hasta donde puede exigir, digamos, probablemente piensa que lo que
necesita es muy complejo para ser resuelto por el software y termina solicitando
una solución a mitad de camino de sus necesidades que no le permite obtener los
resultados deseados. Respecto de este último punto, siempre se debe solicitar “lo
máximo necesario” y luego negociar el alcance final si este máximo no es posible.

Entonces, la especificación de los requisitos siempre debe
ser completa, coherente y lo más detallada posible.
Atención
Ahora, ¿es necesario que el 100% de los detalles se expresen por escrito?
¿Debemos llegar al punto de armar grandes documentos de especificaciones?
La respuesta a este punto ha ido cambiando a lo largo de la historia de la Ingeniería

de Software. En un principio los requisitos se expresaron narrados en lenguaje
natural. Luego aparecieron diversos modelos, como por ejemplo los diagramas
de casos de usos. Más cercanos en el tiempo y dominando la actualidad las
metodologías ágiles han reducido esa documentación y han dado más prioridad
a la comunicación activa y al momento con el usuario.
Esto último es lo que domina la escena actual. Y nació a principios del 2000, y con
la creación del manifiesto ágil dejó sentadas las bases. Copiamos a continuación
una parte de este manifiesto disponible en: http://agilemanifesto.org/iso/es/
manifesto.html
“…hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas

Software funcionando sobre documentación extensiva
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan…”
La idea es valorar más el software funcionando sobre una documentación extensiva

(entre otras de sus requisitos) y suplir esa falta de detalle en la documentación
promoviendo las interacciones y la colaboración con los clientes. Un punto de
vista, a mi parecer, apropiado, más aún porque los requisitos cambian de manera
constante y los desarrollos son extensos en el tiempo, por lo que favorecer la
colaboración y la interacción con el cliente nos ayuda a adaptar el software
desarrollado a lo largo del proyecto sin necesidad de esperar al final del mismo.
Por esto último, uno de los 12 principios del manifiesto ágil menciona:
“Aceptamos que los requisitos cambien, incluso en etapas tardías del

desarrollo”.
Y, otro, lo complementa mencionando:
“El método más eficiente y efectivo de comunicar información al equipo de

desarrollo y entre sus miembros es la conversación cara a cara”.

Sorprendente, y efectivo en la práctica, ahora, para que esto funcione necesita
que se cumpla lo postulado por otros dos de los principios:
“Los responsables de negocio y los desarrolladores trabajamos juntos de forma

cotidiana durante todo el proyecto”.
“Los proyectos se desarrollan en torno a individuos motivados. Hay que

darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo”.
Esto, en cierta forma, traslada la responsabilidad de los requisitos hacia arriba

en la jerarquía de la organización. La gerencia debe asegurar tiempo para y
herramientas a los responsables del lado del negocio para que puedan trabajar
de forma cotidiana junto a los desarrolladores y del lado de los desarrolladores
es también válido.
¿Elimina esta forma de trabajar la ambigüedad? NO, no al 100% al menos. Pero

promueve muchas instancias donde, al nacer la ambigüedad, el desarrollador
puede realizar las consultas necesarias para sacarse las dudas y no hacer
suposiciones o dar por sentado como válidos pensamientos que no lo son.
La mejor especificación de los requisitos, en las

metodologías ágiles, son los canales de comunicación
Atención entre los desarrolladores y el negocio.
Importancia de los requerimientos no-funcionales.
Los requerimientos no funcionales son a menudo más significativos que los

funcionales. Por lo general especifican o restringen características del sistema
como un todo, y eso hace que sea imprescindible el hecho de que sean satisfechos.
Es posible y a menudo ocurre que los usuarios encuentran una forma alternativa
o complementaria cuando una función del sistema no cubre el 100% de sus
necesidades, pero, si lo que no se cubre es un requerimiento no funcional es muy
difícil que los usuarios encuentren una alternativa y esto puede llevar al fracaso.
Los requerimientos no-funcionales están más relacionados con la arquitectura del

sistema que con componentes que implementan una funcionalidad.
Los requerimientos no-funcionales a menudo se expresan como “metas generales”

que al serlo así, terminan siendo ambiguas, por lo tanto la mejor manera de
expresar un requerimiento no-funcional es de una forma cuantitativa de manera
que pueda ser medido al entrar el software en producción.

Tomo aquí un ejemplo de Ian Sommerville en su libro “Ing. de Software 9°
Edición”. El requerimiento expresado de una forma no cuantitativa, y por lo tanto
no deseable sería:
“Para el personal médico debe ser fácil usar el sistema, y este último debe
organizarse de tal forma que minimice los errores del usuario”.
Y luego expresado de una forma cuantitativa que nos permite de alguna forma
medirlo y conocer su cumplimiento.
“Después de cuatro horas de capacitación, el personal médico usará todas las

funciones del sistema. Después de esta capacitación, los usuarios experimentados
no deberán superar el promedio de dos errores cometidos por hora de uso del
sistema”.
A su vez Sommerville propone algunas métricas para ayudarnos en la expresión

cuantitativa:
Tabla de Elaboración propia basada en Sommerville.

Leer
de Requerimientos. Apartado 4.1
Actividad 2: Desafío mental, ¡expresemos de manera

cuantitativa requerimientos no-funcionales!
Actividad
Le presentamos un par de requerimientos no-funcionales.
En base al cuadro mencionado en el último párrafo del texto
Ud. debe expresarlo de manera cuantitativa para poder
luego medirlo y afirmar si el mismo pudo ser satisfecho o no.
Req. 1: “El sistema debe ser rápido, no debo quedar

esperando que cada pantalla reaccione y me devuelva un
dato”.
Req. 2: “El sistema debe ser fiable, si no puedo confiar en

que realizará los cálculos de la facturación y el posterior
asiento contable correctamente no voy a poder usarlo”.

clase 2
Actividad 1: Componentes del dominio de un sistema de facturación.
Enumeración de los conceptos del dominio:
Platos: cualquiera de todos las comidas disponibles dentro del menú vigente para
una sucursal del restaurante.
Postres: cualquiera de todos los postres disponibles dentro del menú vigente para
una sucursal del restaurante.
Bebidas: cualquiera de todos las bebidas disponibles dentro del menú vigente
para una sucursal del restaurante.
Adicionales: ciertos servicios de mesa pueden implicar un costo, esto es variable
en el tiempo. Por ejemplo un panera puede o no implicar un costo, la sal no lo
implica, y cubiertos adicionales si lo implican.
Grupo de Comensales: un unión de comensales que comparten una o más mesas
pero que asisten a la sucursal del restaurante por el mismo motivo.
Comensales: una persona individual que realiza un pedido de algún plato, postre
o bebida que figura en el menú vigente para la sucursal.
Beneficio: un % de descuento sobre el precio de lista del plato, la bebida o el
postre, pero no sobre los adicionales.
Promoción: es la vigencia de un beneficio, para una sucursal y por un tiempo
determinado, expresado como un periodo de tiempo durante el día y la repetición
del mismo a lo largo de varios días determinados de la semana.
Apertura de una mesa: consiste en marcar una mesa como ocupada en el
sistema, indicando el nro. de comensales, la modalidad de facturación y dejando
al sistema atento a la entrada del pedido para ser despachado a la cocina o a la
bodega.
Actividad 2: Desafío mental, ¡expresemos de manera cuantitativa

requerimientos no-funcionales!
Req. 1: “El sistema debe ser rápido, no debo quedar esperando que cada pantalla
reaccione y me devuelva un dato”.
Se puede transformar en una expresión cuantitativa y por lo tanto medible al

entrar el uso el sistema expresándola así:
“El sistema debe ser rápido, no debo quedar esperando más de 5 segundos hasta
obtener una respuesta cuando:
- Realizo click en algún botón
- Abro una pantalla
- Abro un lista desplegable
- Presiono el botón de ayuda
- Tiempo algunas letras en un campo con autocompletado
”.

Req. 2: “El sistema debe ser fiable, si no puedo confiar en que realizará los
cálculos de la facturación y el posterior asiento contable correctamente no voy a
poder usarlo”.
Se puede transformar en una expresión cuantitativa y por lo tanto medible al

entrar el uso el sistema expresándola asi:
“El sistema debe ser fiable, puedo aceptar una factura errónea cada 250 emitidas
y un asiento contable erróneo cada 1000 aceptados por el sistema contable”.
clase 2
conclusiones
Es importante tener en cuenta, durante la etapa de relevamiento de requisitos y su
análisis, armar modelos y glosarios del dominio de la aplicación que favorezcan el
entendimiento entre los participantes del desarrollo, sienten sus bases y permitan
dar el OK de aceptación.
Es muy importante la forma en que se los expresa o el grado de detalle de los
mismos dado que el principal problema que se presenta es la ambigüedad de
entendimiento por parte de los distintos participantes del desarrollo.
Esta ambigüedad se minimiza en las metodologías tradicionales con
documentación más extensa y detallada y en las metodologías ágiles con el
fortalecimiento de los canales de comunicación.

clase 3 DESCUBRIR LOS INTERESADOS A RELEVAR Y COMENZAR CON
introducción ENTREVISTAS
En esta clase vamos a adentrarnos en el mundo del relevamiento. Sí, es un

mundo porque hay muchas técnicas y vamos a ver primero las entrevistas. Aquí
juegan las habilidades interpersonales de la gente de sistemas. Aquí la Ingeniería
deja de ser ingeniería y pasa, de ser una ciencia “dura” (una ciencia exacta) a ser
una ciencia “blanda” (humana).
clase 3
Relevamiento de la información – Los interesados.
tema 1
Los ingenieros de software deben realizar el relevamiento y análisis de los
requisitos. Aquí debemos trabajar con todos los interesados en el proyecto,
no sólo con el cliente (quien solventa económicamente el desarrollo) o con los
usuarios finales (quienes van a usar el proyecto).
Es de vital importancia entonces, que la primera tarea del

relevamiento sea identificar a quienes vamos relevar. En
la jerga de la gestión de proyectos los interesados son
denominados stakeholders, y los definimos como quienes
Atención pueden ser afectados, son afectados o pueden afectar
al proyecto de desarrollo y el software cuando esté en
funcionamiento.
Siempre hay como mínimo 3 interesados:

- El cliente, quien contrata el soft
- El usuario, quien lo va a utilizar
- Los desarrolladores, quienes tienen normas y reglas a cumplir
Pero ¿Quién más puede serlo?
- El área de procesos de la organización que exige como debe

gestionarse el desarrollo.
- Los clientes de la empresa, cuya atención pueden verse afectada por
el sistema.
- La prensa, sobre todo si el software tiene un impacto público.
- Un banco, que otorgue el dinero que financia el desarrollo y puede
requerir cumplir plazos.

- El área de auditoria, que puede requerir cumplir con ciertos
procedimientos.
- La legislación, puede que debamos cumplir ciertas normas legales,
como por ejemplo, facturar el IVA al 21% y no al 19,5%.
La lista puede ser interminable. Ahora, es posible que muchos de los requisitos
plateados por muchos interesados estén ya en conocimiento de los usuarios
mismos del futuro software.
La clave es pensar en las siguientes tres preguntas: ¿A

quiénes afecta el sistema?, ¿A quiénes puede llegar a
afectar el sistema si se modifica su uso esperado o falla?,
Atención
y ¿Quiénes pueden afectar el sistema?
Respondiendo estas tres preguntas repetidas veces, por ejemplo, por medio de la
técnica de BrainStorming y utilizar, por ejemplo, Freemind como herramienta para
llevarla a cabo, obtendríamos una de las bases para comenzar el requerimiento:
el listado de interesados.
LECTURA COMPLEMENTARIA
Le sugerimos buscar y leer sobre la técnica BrainStorming https://
es.wikipedia.org/wiki/Lluvia_de_ideas y la herramienta Freemind
Leer
http://freemind.sourceforge.net/wiki/index.php/Main_Page
Actividad 1: ¡Identificamos requerimientos!
1- Lea el siguiente texto.

Actividad
2- Identifique y escriba los requerimientos de los usuarios
teniendo en cuenta los siguientes interrogantes:
¿Con quién supone que está hablando Ibañez?
¿Qué interesados detecta?

“Como le decía Ibañez, tenemos que agiornar nuestro sistema. No puede ser
que cada vez que tengamos que vender un equipo, o hacer un cambio por falla
del equipo, tengamos que hacer la factura a mano. Tampoco tenemos acceso
al talonario de facturación, se lo tenemos que pedir a la gente de la oficina de
facturación.
Esto consume mucho tiempo y más si queremos que la primera línea de atención
sea la que realice la venta del equipo. Deberíamos poder facturar cualquier
artículo que este en el stock de la sucursal, y en la 1° línea de atención, en el
mostrador.
Ahora, el mostrador debe conocer cuántos equipos hay y de cada modelo en
stock, y cuantos están disponibles y cuantos comprometidos en una venta que
el cliente aun no retiro.
Ojo, no se olvide Ibañez, que cada equipo tiene un costo de envío distinto, y
que ese costo también varía según sea capital, interior de la provincia u otra
provincia, y que los de La Pampa para abajo tienen el extra de 20%. Es que
algunos, los podemos despachar por correo argentino, pero los más grandes,
no hay caso, van por comisionista o un transportista. Sepa Ibañez, que tanto el
correo argentino como los transportistas tienen una pila de requisitos, siempre
me piden el remito, porque si los para la caminera, tienen que justificar la
mercadería que llevan, el sistema debería imprimir el remito y con respecto al
correo, me parece que tiene un servicio online para que tomemos el tracking,
¿ se quiere fijar en eso?”.
Luego de realizar la actividad donde identificaron los requerimientos, vamos a

desarrollar el próximo paso que los ingenieros de software con los interesados
del sistema realizan para descubrir el dominio de aplicación, qué servicios debe
proporcionar el sistema, el desempeño requerido de éste, las restricciones de
hardware y otros.
El proceso de “levantar” los requerimientos no es un proceso lineal, es más bien un

proceso iterativo, donde vamos profundizando los requerimientos. Este proceso
se llama habitualmente “Elicitación de Requerimientos”. Veamos de qué se trata.

Mientras realicemos los relevamientos se van a presentar dificultades. A
continuación vamos a ver algunas de ellas:
Los usuarios no siempre saben lo que quieren con el detalle que necesitamos
y solo pueden enunciarlo con una frase general.
Ejemplo: “El sistema debe emitir la factura”
A veces se expresan necesidades inalcanzables, al menos en los tiempos

y el costo establecido para el proyecto. Pero este punto no siempre nos
vamos a dar cuenta al momento de relevar el requerimiento.
Ejemplo: supongamos un sistema informático que hace el recuento de los votos

de los ciudadanos en las elecciones generales, y nos plantean el requisito de “el
sistema debe enviar un SMS a cada votante entre las 20 y las 20:30 informando
el resultado de la elección”… al avanzar el análisis vemos que el nro. estimado
de votantes es de varias decenas de millones y el sistema de mail simplemente
no puede enviar esa cantidad de e-mails en ½ hora.
Cada interesado va a expresar los requerimientos de acuerdo a su punto de

vista y de acuerdo a los que el mismo priorice, que no necesariamente va a
ser lo que prioricen los restantes.

Ejemplo: volvamos al sistema de facturación, los usuarios que realizan la factura
no quieren tener que escribir el código de cada material al cargar una factura,
pero… el área de stock si lo necesita para poder dar de baja los materiales
vendidos del stock. Por lo tanto, quienes cargan la factura solo querrán que el
sistema les permita ingresar un texto libre describiendo el material, y la gente de
stock querrá que se busque o escanee el código de barra exacto de cada uno de
los materiales.
Para finalizar este tema, presentamos dos ideas importantes a tener en cuenta:
Los requerimientos van a cambiar con el paso del tiempo. No vivimos en un

mundo estático. Por lo tanto, conseguir los requerimientos no es una tarea que
ser realice una sola vez, sino, una tarea continua.
Quien nos da la información puede ocultarla, ser reacios a colaborar, pueden

no poder expresarla, o simplemente estar limitados de tiempo para dedicarle.
clase 3 Introducción a las técnicas de Relevamiento

tema 2
Debemos descubrir, u obtener, los requerimientos, recopilarlos y clasificarlos.
Podemos obtenerlos principalmente de participantes del proyecto, de usuarios,
de otros documentos, de especificaciones de sistemas similares. Principalmente
vamos a hacerlo a través de la comunicación con el cliente, con los usuarios y con
los demás interesados. Hay un grupo de técnicas recomendadas.
Existen cinco técnicas recomendadas principales:
1. Entrevistas / Encuestas
2. Escenarios
3. Prototipos
4. Reuniones moderadas
5. Observación

(Existen muchas más técnicas)

Existen algunos factores comunes a todas las técnicas,
necesarios para obtener el éxito:
- La experiencia del elicitador.
- Tener presente las características de los
requerimientos.
Atención
- Ser ordenados al tomar apuntes y clasificarlos.
- Armar un diccionario de términos datos.
Primer Técnica: Entrevistas
Una entrevista es “Un intercambio de ideas, opiniones

mediante una conversación que se da entre una, dos o
más personas donde un entrevistador es el designado
Atención para preguntar”.
A continuación lea el texto: ¿Qué es entrevista? ic 1

Leer
El entrevistador es parte del equipo de sistemas y los entrevistados son por lo

general los usuarios.
Las entrevistas pueden clasificarse de dos maneras distintas:
· Según su grado de formalidad:

o Formales
o Informales
· Según la rigidez del plan
o Abiertas
o Cerradas

La formalidad de una entrevista la da el contexto de trabajo, una entrevista
formal es una entrevista planeada dentro de un plan de trabajo difundido en la
organización con fechas, un lugar y responsables establecidos. Por el contrario,
una entrevista informal puede darse en la cafetería de la empresa que aunque no
fuese planeada los datos que aporta son tan valiosos como los obtenidos de en
las formales.
Las entrevistas abiertas no tienen un listado de preguntas

predefinidos sino más bien ciertos temas que deben ser
tratados y los mismos son explorados por los participantes.
Como contraposición, las entrevistas cerradas ya tienen
Atención
una agenda de temas a tratar cada uno con sus respectivas
preguntas.
En el día a día, las entrevistas tienen un cierto grado de planeamiento, al menos

con un listado de grandes temas y posiblemente dudas de una entrevista
anterior, pero, a medida que se van desenvolviendo es muy usual que deriven en
entrevistas abiertas y más aún cuando comienza a hacerse foco en requerimientos
específicos.
¿Qué ventajas tienen las entrevistas? Son muy útiles

para conocer los requisitos de los usuarios, como se ven
ellos trabajando en el sistema. Pero fallan en servirnos
para inferir el dominio, dado que muchas veces los
usuarios lo conocen tan bien que dan por sentado que
ya lo conocemos y no lo mencionan. Por otra parte, es
Atención muy seguro que los entrevistados den sus respuestas
con vocabulario propio de la jerga técnica, que es muy
posible que los entrevistadores no lo conozcan, y es un
buen puntapié para hacer una entrevista específica del
dominio.

Hay puntos a tener en cuenta para que la entrevista sea efectiva:
- No hay que tener ideas preconcebidas, hay que ir con la mente

abierta y dispuestos a escuchar.
- Hay que tomar nota de lo que nos dicen, lo fundamental, luego se
puede profundizar en otras entrevistas.
- Hay que preguntar varias veces “porque”. Cuando el entrevistador
dice algo que no entendemos debemos preguntar porque 3 o 4 veces
ante cada respuesta.
- A los entrevistados les cuesta hablar “en términos generales” para
ellos es mejor hablar de temas específicos, de los cuales luego
tenemos que hacer los nexos.
A continuación les proponemos leer el siguiente ejemplo:
Estamos preguntando a los vendedores cómo realizan hoy en día el cobro con
tarjeta de crédito para darle soporte con el sistema, digamos, realizar un posnet
que funcione en la PC y descubrir mejoras.
Hay dos participantes: E – entrevistador y F – usuario:

E – contame, qué pasos seguís para cobrar al cliente cuando te manifiesta que
quiere pagar con tarjeta.
F – bueno, yo le paso la tarjeta por el posnet y luego cargo el cupón en el
sistema.
E – ¿Cargas el cupón? ¿Qué viene siendo? ¿Lo escaneas y el sistema guarda
la imagen?
F – noooo, solo cargo el nro. Cuando el sistema va a emitir la factura.
E – bien, tomo nota, ahora, que datos ingresas en el posnet.
F – se ingresa el monto, los últimos 4 dígitos de la factura y se selecciona el
plan de pagos, o sea, las cuotas.
E – y esas cuotas, ¿las ingresas a mano? ¿son libres? ¿o las elegís de una
lista?
F – las elijo de una lista, cada tarjeta tiene distintas cantidades de cuotas,
según el convenio con el banco.
E – OK, perfecto. Y las tarjetas ¿recibimos todas las que hay?
F – no, no todas, es como las cuotas, según las que estén dentro del convenio
con los bancos.
E – ¿y que pasa si tratas de cargar una que no está en el convenio?
F – no se puede, el sistema no te deja
E - ¿no te deja? ¿Cómo es eso?
F – simplemente no está para elegirla
E – ahh ahora sí, hay un listado de tarjetas vigentes y cuando elegís una te
muestra las cuotas posibles.
F – Claro! Es así. Y te agrega un dato más, muestra también el intereses,
ponele, vos elegís VISA 18 cuotas y te dice 3% de interés.
E – ¿y te sirve que sea así? ¿es cómodo? ¿es rápido?
F – y… no, el listado de tarjetas no esta ordenado, y las tarjetas se repiten, solo
que se le agrega el banco emisor al lado. Esto es porque a veces, la misma
tarjeta, la misma cantidad de cuotas, para dos bancos distintos, tiene distinto
interés, o por ahí una tiene una promo con 0% interés.
E – Fantástico, tiene que estar ordenado, ¿y cómo es mejor? ¿alfabéticamente?
F – No, mira, el 80% de las compras se hace con 3 tarjetas distintas, con que
esas 3 estén primeras es suficiente.
…
Este ejemplo, es una entrevista típica con un usuario. Como vemos, sólo una
pregunta está pautada, preguntar cómo se realizaba el cobro con tarjeta, cuáles
son los pasos. Lo demás fue surgiendo de la charla misma. Tengamos en cuenta
este ejemplo para hacer la actividad 2.

Para ampliar el contenido de este tema, lea el siguiente
apartado:
de Requerimientos. Apartado 4.5.
Actividad 2: Entrevista de relevamiento
A partir del dialogo presentado en el ejemplo:

Actividad
1-
a- Elabore un listado de los pasos (cobro con tarjeta).
¡Atención! : lo más detallado posible
b- Elabore un listado con los requisitos que nos plantea
el usuario.
2- Continuemos con la entrevista: ¿Qué preguntas le haría
al usuario para conocer como es el cobro con tarjeta de
débito? ¡Adelante!
clase 1
tema 1
Información complementaria 1
¿Qué es Entrevista?
Una entrevista es un intercambio de ideas, opiniones mediante una conver-

sación que se da entre una, dos o más personas donde un entrevistador es
el designado para preguntar. Todos aquellos presentes en la charla dialogan en
pos de una cuestión determinada planteada por el profesional. Muchas veces
la espontaneidad y el periodismo moderno llevan a que se dialogue libremente
generando temas de debate surgidos a medida que la charla fluye.
Una entrevista es recíproca, donde el entrevistado utiliza una técnica de recolec-

ción mediante una interrogación estructurada o una conversación totalmente
libre; en ambos casos se utiliza un formulario o esquema con preguntas o cues-
tiones para enfocar la charla que sirven como guía. Es por esto, que siempre
encontraremos dos roles claros, el del entrevistador y el del entrevistado (o
receptor).

El entrevistador es quien cumple la función de dirigir la entrevista mediante la
dominación del diálogo con el entrevistado y el tema a tratar haciendo preguntas
y a su vez, cerrando la entrevista. A continuación desarrollaremos los dos tipos
principales de entrevistas.
Entrevista estructurada y estandarizada
En el primer caso hablamos de una entrevista formal y estructurada (también

llamada estandarizada) que se caracteriza por estar planteada de una manera
estandarizada donde se hacen preguntas que previamente fueron pensa-
das y para un entrevistado en particular que responde concretamente lo que se
le está preguntando. Por esta razón, el entrevistador tiene una libertad limitada
a la hora de formular las preguntas pues no pueden nacer de la entrevista en sí
misma, sino de un cuestionario realizado de ante mano. De todas formas, esta
metodología tiene beneficios así como también algunas desventajas que serán
detalladas a continuación.
En primer lugar, si hablamos de ventajas proporcionadas por esta tipología,

la información es fácil de interpretar favoreciendo el análisis comparativo;
el entrevistador no requiere tener mucha experiencia en la técnica ya que es
cuestión de seguir el cronograma de preguntas. En segundo lugar, si tenemos
en cuenta las desventajas que se dan podemos hablar sobre las limitaciones
a la hora de profundizar en un tema que surja en la entrevista ya que, al
no permitirse que el diálogo fluya naturalmente es muy complicado que estas
cuestiones se den.
Entrevista no estructurada y libre
En el segundo caso hacemos mención a una entrevista no estructurada que es la

clara oposición de una entrevista estructurada por diferentes motivos. Es flexible
y abierta ya que, por más de que haya un objetivo de investigación (que es lo
que rige a las preguntas) no se espera que sus respuestas se vean compuestas
de un contenido ordenado y con cierta profundidad. Si hablamos del rol que le
toca al entrevistador, afirmamos que él es el encargado de elaborar preguntas
pero (a diferencia de la entrevista formal) no debe seguir un cronograma de
orden sobre la forma de llevar las preguntas y la formulación de las mismas.

Este tipo de entrevista tiene muchísimas ventajas como por ejemplo, al ser re
adaptable y libre se logra la generación de un clima ameno que habilita
la profundización sobre los temas de interés. De todas formas, no todas son
ventajas ya que al requerirse de mayor tiempo (porque los temas suelen
expandirse) es más costosa de realizar por el tiempo empleado por parte del
entrevistador. Asimismo, el entrevistador requiere ser una persona con una gran
técnica e informada en el tema a tratar para poder tener argumentos y opiniones
para profundizar y dialogar.
Vale aclarar que dentro de este tipo de entrevista nos encontramos con una sub-
división de tres: entrevista a profundidad, entrevista enfocada y entrevista
focalizada.
Fuente http://concepto.de/que-es-entrevista/#ixzz504NqZDrT

clase 3
Actividad 1: ¡Identificamos requerimientos!
1. Actualizar el sistema
2. No facturar manualmente con un talonario sino en el sistema
3. Mostrar el stock de la sucursal x modelo, indicando disponibles y
comprometidos
4. Mostrar el costo de envío discriminado por capital, interior u otra provincia
5. Agregar el 20% extra a los envíos a provincias de la Patagonia
6. Indicar si el envió puede ser despachado por correo argentino o debe ser
despachado por transportista
7. Imprimir los requisitos para el envió: carta de porte o remito
8. Mostrar el nro. de tracking si el pedido fue despachado por un medio que
lo dispone
- Suponemos que Ibañez, de sistemas, está hablando con el usuario que

va a utilizar el nuevo sistema.
- Otros interesados: los transportistas, el correo, el gestor del stock, la
oficina de facturación.
Actividad 2: Entrevista de relevamiento
Pasos:
- Seleccionar la tarjeta o pasarla por el posnet
- Seleccionar las cuotas
- Ingresar el importe
- Ingresar los últimos cuatro dígitos de la factura
Requisitos:
- Las cuotas no son de libre ingreso, se deben tomar de una lista
- La lista de cuotas debe mostrar las cuotas vigentes de la tarjeta elegida
o escaneada
- El sistema debe controlar que la tarjeta pasada por el posnet esté vigente
- El listado de tarjetas (si no se pasa por posnet) debe mostrar primero las
3 tarjetas más usadas y luego el resto alfabéticamente

Continuando la entrevista:
- ¿y con débito cuales son los pasos?
- ¿ingresas algún dato además del monto y los últimos 4 dígitos?
- ¿Qué sucede si la respuesta de posnet es un error?
- ¿Cómo anulas el pago si el cliente se arrepiente?
(puede haber muchas preguntas)
clase 3
conclusiones
Lo que hemos visto hasta el momento nos permite discernir un paso previo a
realizar antes de comenzar el relevamiento:
- Pensar a quiénes, o a qué, vamos a relevar, tratando de no dejar
afuera a ningún interesado para que luego nuestro sistema no
encuentre oposición o esté incompleto.
Y comenzamos a ver esa parte blanda de la ingeniería de software donde juegan

más las relaciones entre las personas y la capacidad de comunicación que la
matemática y la lógica: el relevamiento en sí mismo en una 1° técnica, la entrevista.

clase 4 DOS TÉCNICAS QUE SE POTENCIAN AL TRABAJAR JUNTAS
introducción
Lo que buscamos en esta cuarta clase es que conozca dos técnicas de
relevamiento que pueden ser utilizadas por separado pero que juntas son mucho
más eficaces. Las técnicas son Prototipos y Escenarios. No son técnicas para
comenzar el relevamiento desde cero, sino que son técnicas para utilizar cuando
ya tenemos un mínimo de ideas de lo solicitado. Se usan para “bajar a tierra”
las ideas abstractas y subjetivas, que se conversan durante las entrevistas, ya
que tienen el poder de mostrar ejemplos, modelos, pantallas o comportamientos
concretos del futuro sistema.
clase 4 Relevamiento – Técnica: Prototipos

tema 1
Esta técnica, la creación de prototipos, es una técnica “mixta” entre relevamiento y
los pasos próximos, la verificación de los requerimientos y el análisis. No conviene
utilizarla desde el inicio del relevamiento, sino cuando éste ya avanzó. Es muy útil
para comenzar a igualar las expectativas de los interesados con respecto a las
interfaces dado que al mostrar modelos de pantallas y reportes permite al usuario
“entender de qué estamos hablando”. Realizar un prototipo no es otra cosa que
diseñar un interface de usuario o un reporte sin funcionalidad o con una mínima
funcionalidad o simplemente dibujos de cómo sería.
Por lo general los utilizamos después de la primera entrevista, cuando el

usuario ya nos ha detallado una serie de requisitos.
Armar prototipos puede ser muy simple o muy complejo. Si usamos una
herramienta de prototipado es simple, si utilizamos el lenguaje de programación
elegido puede llegar a ser más complejo.
Ahora, como antes mencioné no debemos hacer prototipos muy elaborados, son
solo una ayuda al entendimiento con el usuario, para que entre todos tengamos
una visión compartida.
Una buena herramienta gratis para hacer prototipos es: Pencil Project https://
pencil.evolus.vn
A continuación le presentamos un tutorial para que

comience a explorarla: https://www.youtube.com/
watch?v=A6yHmjPuPO0

¿Y cómo se ve un prototipo de una pantalla? El siguiente es un ejemplo que pudo
ser armado a partir de los primeros relevamientos:
Una vez armado un prototipo se concreta una nueva reunión con el usuario,
esta vez para mostrarle el prototipo y/o, si el mismo tiene cierta funcionalidad,
solicitarle que lo use. Llegados a este punto el profesional de sistemas debe
estar atento a los comportamientos de los usuarios cuando utilizan el prototipo y
al mismo tiempo escuchar el feedback por ellos proporcionado. Incluso es muy
bueno trabajar junto con los usuarios al realizar el prototipo explicándoles sobre el
uso de la herramienta de prototipado y haciendo los cambios mismos acordados
durante la reunión.
Los nuevos requisitos a los que debemos apuntar con el prototipo son:
• Información en pantalla: saber si estamos mostrando toda la información

necesaria y si no estamos mostrando información no necesaria.
• Botones de acción: saber si están correctamente ubicados y si están
todos. Si dos acciones que deben ser independientes no las hemos
generalizados en un solo botón.
• Listas de opciones: saber si están las lista de opciones necesarias.
• Navegación: saber si la navegación por la pantalla es la correcta. Si el
usuario no se confunde. Si ante un error la pantalla queda en el estado
correcto.
• Mensajes de error: conocer si existe algún área de la pantalla donde
veamos los mensajes de error, que tan detallados son y que tanta ayuda
brindan al usuario.

• Mensajes de información/log de acciones: conocer si existe algún área
de la pantalla donde veamos los mensajes de información o donde la
pantalla vaya logueando lo que sucede.
• Pasos y guiado del usuario a lo largo de la pantalla: muy relacionado con
la navegación, la idea es saber si la pantalla misma va guiando al usuario
a realizar lo que espera poder realizar en la pantalla.
• Ayuda en la pantalla: verificar si existe una forma de acceder a la ayuda
desde la pantalla misma.
Con estos nuevos requisitos volvemos a modificar el prototipo y luego a reunirnos

nuevamente con el usuario.
Pueden realizarse prototipos de otros componentes de sistema, pero el más

utilizado para relevar requisitos con los usuarios son los prototipos de pantallas.
¿Qué ventaja nos provee?

Como lo explicamos antes, relevar requisitos por medio
de entrevistas es lograr que el usuario “traslade” con sus
mejores palabras, las ideas que tiene en la mente y tratando
de formar algo similar en la mente del entrevistador, algo
muy difícil. Pero, al trabajar con prototipos se habla ya
sobre objetos “concretos”, sobre una representación en
común de las ideas del entrevistador y el entrevistado.
Atención
Otra ventaja que nos provee es que el prototipo no es una
pantalla, requiere trabajo pero no tanto como desarrollar
la pantalla entera. Podemos modificarlo muchas veces
hasta lograr un consenso, evitando futuras modificaciones
a realizarse una vez que termina el desarrollo, momento
en el que es más costoso realizar los cambios.

Pearson Educación. México. 2011.
• Capítulo 2 – Procesos de Software. Apartado
2.3.1
• Capítulo 4 – Ingeniería de Requerimientos.
Apartados 4.5 y 4.6

Actividad 1: Pantalla para la cocina
Para esta actividad supongamos que estamos desarrollando

Actividad
un software para una cadena de restaurantes de la ciudad.
Relevamos con algunos de los usuarios, particularmente
con los cocineros, cómo les gustaría que fuese la pantalla
donde ellos reciben todas las órdenes que los mozos han
levantado del salón. Esta pantalla está siempre activa y es
la única que ven los cocineros. Está ubicada en un televisor
de 45” en un rincón de la cocina. La misma no tiene asociada
un teclado o mouse, solo es informativa.
A partir de esta información elabore un prototipo. Puede

emplear la herramienta antes mencionada, o simplemente
dibujar con lápiz en un papel (algo tan válido como la
herramienta).
Relevamiento – Técnica: Escenarios

clase 4
tema 2 Una de las ventajas de los prototipos era que nos permitía dialogar con los
usuarios sobre “algo concreto”. Los escenarios también, aunque a mitad de
camino. Los escenarios son descripciones de sesiones de interacción entre los
usuarios y el sistema. Los prototipos pueden ser estáticos, o dinámicos, pero
libres, no guiados.
Al contrario, un escenario es la secuencia de uso de las interacciones entre

el usuario y el sistema. Al igual que los prototipos es necesario al menos un
relevamiento mínimo previo que nos permita armar uno básico. Y al igual que
los prototipos a medida que los vamos revisando con el usuario van apareciendo
detalles que no conocíamos y que van enriqueciendo el escenario y por lo tanto
los requisitos que le dieron origen.

Existen algunos puntos mínimos que debemos tener en cuenta al armar un
escenario:
• Una descripción de lo que esperan del sistema los usuarios cuando inicia
el escenario.
• Una descripción del flujo normal de los eventos.
• Una descripción de lo que puede salir mal y cómo se manejaría.
• Información de otras actividades que estén en marcha al mismo tiempo.
• Una descripción del estado del sistema cuando termina el escenario.
Cada uno de estos puntos debe ser narrado en lenguaje natural.
Estos requisitos son similares a los de un caso de uso o más similares a los de
un caso de prueba.
Veamos un ejemplo:

Escenario: Cobro con Tarjeta AMEX
Suposición Inicial: el cliente manifiesta su voluntad de pagar la compra con

tarjeta de crédito pero previamente desea conocer los planes de pagos con la
tarjeta mencionada para seleccionar el más adecuado a sus necesidades.
Flujo Normal: el vendedor selecciona en el sistema, al momento de cargar

las formas de pago para la venta del/de los artículo/s, la tarjeta que el cliente
menciona y presiona “+” para expandir el listado de opciones la misma. Al
expandirse se ven todos los bancos emisores, la cantidad de cuotas que ofrece
cada uno y el interés de cada cantidad de cuotas.
El vendedor lee estos datos al cliente quien elige una y se lo manifiesta al
vendedor.
El vendedor hace click en el sistema sobre las cuotas elegidas y el sistema
calcula automáticamente el monto final (intereses incluidos) y el monto de cada
cuota.
El vendedor informa el monto final y el monto de cada cuota al cliente y pregunta
si lo confirma.
El cliente responde que si quiere confirmar.
El sistema se comunica con el emisor de la tarjeta para enviar la operación.
El emisor de la tarjeta devuelve el ok de la operación.
El vendedor presiona el botón que emite el comprobante para que el cliente
firme (el cupón de pago).
El vendedor carga el cupón de pago en la venta.
Que puede salir mal: que el emisor de la tarjeta simplemente no responda

y el procedimiento se cancele por time out. En este caso se debe permitir al
cliente seleccionar otra forma de pago para concretar la venta.
Otras actividades: al mismo tiempo el sistema se va comunicando con el

webservice de veraz para conocer que tan buen pagador es el cliente con
sus deudas y lo reporta por pantalla (pero lo reporta de manera binaria: BUEN
PAGADOR o MAL PAGADOR).
Estado al finalizar: al finalizar el sistema debe dejar asentada la transacción

en la base de datos.
Como antes mencionamos esta técnica se complementa muy bien con la de

prototipos pudiendo mostrar en los puntos “Flujo Normal” y “Que puede salir mal”
como se verían estas actuaciones por pantalla. De esta manera pasaríamos
de una idea abstracta y subjetiva que nació de una charla entre los interesados
y los profesionales de sistemas en modelos concretos de la apariencia y el
comportamiento del sistema.

Para ampliar el contenido de este capítulo lea el siguiente
Leer
Pearson Educación. México. 2011. Capítulo 4 – Ingeniería
de Requerimientos. Apartados 4.5.1 y 4.5.3
Actividad 2: Enlacemos las dos técnicas Prototipos y

Escenarios
Actividad
En el tema anterior mostramos un prototipo de una pantalla
de cobro con tarjeta como ejemplo, y en este tema mostramos
un escenario que utiliza dicha pantalla. La consigna de esta
actividad es evolucionar el prototipo y el escenario y juntarlos
en un mismo entregable para el usuario. ¡Adelante!
clase 4
Actividad 1: Pantalla para la cocina
La actividad no tiene una respuesta única. Puede tener muchas distintas. Aporto
una posible:
Como claves para la corrección si o si debemos tener un listado de las ordenes,

ordenadas en el tiempo o por su antigüedad, su contenido, y la mesa a la cual se
refieren, o el nro. de pedido.

Actividad 2: Enlazamos las dos técnicas, prototipos y escenarios.
El escenario evolucionado podría ser así:
Escenario: Cobro con Tarjeta de Crédito.
Suposición Inicial: el cliente manifiesta su voluntad de pagar la compra con una

de las tarjetas de crédito válidas, las que recibe el comercio, pero previamente
desea conocer los planes de pagos con la tarjeta que el posee, para seleccionar
el más adecuado a sus necesidades; entendemos como plan a una combinación
cantidad de cuotas e intereses.
Flujo Normal: el vendedor selecciona en el sistema, al momento de cargar las

formas de pago para la venta del/de los artículo/s, la tarjeta que el cliente menciona
y presiona “+” para expandir el listado de opciones la misma. Al expandirse se
ven todos los bancos emisores, la cantidad de cuotas que ofrece cada uno y el
interés de cada cantidad de cuotas.
El vendedor lee estos datos al cliente quien elije una y se lo manifiesta al vendedor.
El vendedor hace click en el sistema sobre las cuotas elegidas y el sistema calcula
automáticamente el monto final (intereses incluidos) y el monto de cada cuota.
El vendedor informa el monto final y el monto de cada cuota al cliente y pregunta
si lo confirma.
El cliente responde que si quiere confirmar.
El vendedor solicita al cliente que ingrese en un teclado numérico aparte los 16
dígitos de la tarjeta, luego la fecha de vencimiento y luego el código de seguridad.
Cuando el cliente ya a tipeado los datos se lo manifiesta al vendedor.
El vendedor presiona “Procesar”.
El sistema se comunica con el emisor de la tarjeta para enviar la operación.
El emisor de la tarjeta devuelve el ok de la operación.
La pantalla sola emite el comprobante para que el cliente firme (el cupón de
pago).
El cupon queda asociado automáticamente a la venta.
El vendedor presionar “Volver” para regresar a la pantalla de facturación.
Sigamos estos pasos en el siguiente prototipo de la pantalla:

Qué puede salir mal: que el emisor de la tarjeta simplemente no responda y el
procedimiento se cancele por time out. En este caso, se debe permitir al cliente
seleccionar otra forma de pago para concretar la venta. Para seleccionar otra
forma de pago debe presionar “Volver”.
Otras actividades: al mismo tiempo el sistema se va comunicando con el

webservice de una entidad de análisis de riesgo de clientes para conocer que
tan buen pagador es el cliente con sus deudas y lo reporta por pantalla (pero lo
reporta de manera binaria: BUEN PAGADOR o MAL PAGADOR).
Estado al finalizar: al finalizar el sistema debe dejar asentada la transacción en la

base de datos. La operación contra la tarjeta debe estar OK. Los comprobantes,
original y duplicado de la venta deben haber sido emitidos.
clase 4
conclusiones
Lo que hemos visto hasta el momento nos permite no solo evolucionar los
requerimientos al ampliarlos trabajando de manera conjunta con el usuario y
otros interesados, sino que también nos permite ir verificando los requisitos que
ya habíamos relevado y que dieron origen a los prototipos y a los escenarios.
Entonces, llegados a este punto de las clases ya tenemos una “Estrategia” de

cómo encarar las tareas de levantar requerimientos:
1. Primero, concretamos entrevistas con los interesados.
2. Segundo, armamos prototipos y escenarios de lo relevado.
3. Tercero, en nuevas reuniones con los interesados verificamos los
prototipos y los escenarios y en nuevas charlas con los clientes.
4. Volvemos al paso 2. Reorganizamos y evolucionamos los prototipos y
escenarios.
5. Finalizamos cuando el cliente nos dio su OK o cuando consideramos que
ya tecnología empleada no cubre lo solicitado.

clase 5 MÁS TÉCNICAS: REUNIONES MODERADAS Y OBSERVACIÓN
introducción
Lo que buscamos en esta quinta clase es que conozca dos técnicas más de
relevamiento. Éstas, al contrario de las dos anteriores no se potencian entre sí y
tienen objetivos distintos. Las técnicas son Reuniones Moderadas y Observación.
Ambas son técnicas para comenzar el relevamiento desde cero, y sirven para
conocer el proceso de negocios que será soportado luego por el sistema, o
también del dominio de la aplicación.
Las Reuniones Moderadas son una forma de mejorar las entrevistas, que al ser
libres, pueden ser desordenadas. Por otro lado, la Observación, que también
es una técnica mixta, nos permite descubrir los requisitos que no obtuvimos en
las reuniones o entrevistas dado que es posible que los usuarios no mencionen
siempre toda la información necesaria.
clase 5 Las Reuniones Moderadas como técnicas de relevamiento

tema 1
Como mencionamos en la introducción las Reuniones Moderadas se usan para
superar el “desorden” que suelen ser las entrevistas. La idea principal es
tener una Agenda de Temas a tratar y ciertas pautas de comportamiento, más
algunos temas previos a tener en cuenta en la preparación. Veamos uno por uno
estos puntos y sus consideraciones.
1- Preparación de la Reunión: es una fase previa donde debemos

asegurarnos de cumplir algunas pautas que nos van a facilitar la misma.
- Debemos tener designado un “facilitador” que llevará adelante la

reunión velando por el cumplimiento de los tiempos y de los temas.
- Debemos tener designado un “escriba” que tome notas rápidamente
de lo hablado y remarque los consensos.
- Acordar el día, el horario y la duración de la reunión.

- Armar, desde el lado de sistemas, la agenda de temas a tratar y
ordenarlos desde el más importante al menos importante.
- Determinar y asegurar la existencia de un soporte de trabajo, por
ejemplo, un pizarrón, un proyector, elementos para la toma de nota.
2- Durante la Reunión: el facilitador mismo es quien lleva adelante la

reunión, controlando los tiempos y el tratamiento de tema y verificando
al cerrar cada uno que todos lo hayan comprendido y anotando dudas o
temas para una próxima reunión. Por cada tema a tratar se debe pensar,
como ayuda:
- Listar los objetos o datos que recibe el sistema

- Listar los objetos o datos que produce el sistema
- Listar los procesos con los que interactúa el sistema
- Pensar los estados de los transacciones
- Criterios para validar la actuación del sistema
3- Finaliza la reunión: la persona designada como “escriba” debe armar

una minuta breve de la reunión detallando los temas que se trataron y el
consenso al que se llegó en cada uno de ellos y fijando, de ser necesario,
la fecha de la próxima reunión. A su vez debe referenciar donde se
almacenan los detalles de cada tema tratado.
Por supuesto que esta técnica puede tener infinitas variantes, pero ciertos puntos
mínimos se deben cumplir:
- Debe existir un rol de “facilitador” y uno de “escriba”

- Debe tener una agenda de temas ordenadas desde lo más a lo
menos importante
- Debe tener una minuta resumen
- Deben quedar almacenados los resultados

Cumpliendo estos puntos ya se le da un marco de formalidad.
Debemos tener en cuenta que cada organización tiene

ciertas normas para la realización de reuniones en
algunos casos explicitas y otros implícitas. Por ejemplo,
la necesidad de reservar con tiempo una sala de reunión
o el material a utilizar, o la necesidad de notificar y/o pedir
Atención
permiso a un jefe para que su dependiente concurra a
la misma. O un espacio compartido donde se debe
almacenar los resultados de la Reunión.

Volviendo al ejemplo recurrente en las clases vamos al caso de la venta con tarjeta
de crédito. Supongamos que nos hallamos en una etapa previa a la realización
del prototipo. Entonces una “Agenda de Temas a tratar” priorizados podría ser así:
· Explicar los pasos del proceso de cobro con Tarjeta de Crédito.

· Enumerar los controles que realiza el usuario o que debería realizar
el sistema en cada uno de ellos.
· Los datos de las tarjetas ¿deben estar visible en la pantalla?
· …
Puede ocurrir que la Reunión Moderada sea una segunda parte de una entrevista
donde ya es necesario evitar pérdidas de tiempo y relevar de manera repetida.
Los Puntos de Vista
Como complemento a las Reuniones Moderadas existe otra “técnica” o “Forma

de Encarar” el relevamiento de requerimientos que se denomina “Viewpoint-
oriented approaches to requirements” (enfoque en los requerimientos orientado
de los puntos de vista).
Los Puntos de Vista es más una técnica para organizar los requerimientos
basados en la perspectiva de los usuarios y los administradores de los procesos
de negocios. También, nos permite clasificar a los interesados en el sistema, lo
que nos permite enfocarnos hacia cada uno de ellos con cierto tipo de preguntas.
A la vez es muy útil para dejar en claro los conflictos en los requerimientos
planteados por distintos interesados, dado que por lo general los conflictos
tienden a aparecer cuando los usuarios/interesados son de distintos niveles
o de distintos grupos de trabajo.
Al reconocer esta técnica, existen diferentes puntos de vista respecto de lo mismo

que hace o debería hacer el sistema:
1. Punto de vista del interactuador: son los interesados que interactúan

con el sistema. Cuando los interesados de este grupo nos aporten
los requerimientos, vamos a ver que el grueso de los mismos
corresponden las características e interfaces del mismo.
2. Punto de vista del indirecto: son los interesados que no usan el
sistema pero que en algún momento reciben algo del mismo. Por lo
general aportan restricciones impuestas por el entorno que provienen
de mandos superiores.

3. Punto de vista del dominio: representa a las características y reglas
de negocio que influyeron en los requerimientos del sistema. Por lo
general aportan restricciones que aplican al sistema en sí.

apartado del libro que conforma la bibliografía básica:
Leer
de Requerimientos. Apartados 4.5 – Link al capítulo digital:
http://www.SoftwareEngineering-9.com/Web/Requirements/
Viewpoints.html
Actividad 1: Vamos a planear una Reunión Moderada
Lea el siguiente enunciado: “A partir de la 1° entrevista

Actividad
con el Jefe de Cajeros determinamos temas que debemos
profundizar respecto al cobro de productos con Tarjeta de
Crédito”. Supongamos ahora que Uds. dirige el equipo de
personas que va a organizar dos reuniones.
Se solicita que se armen las tarea “Previas a la reunión…” y,

simulando, “lo que se puede obtener como resultados”.
¡Adelante!

clase 5 RELEVAMIENTO – Técnica: La Observación
tema 2
Consiste básicamente en observar al usuario en el desarrollo de sus tareas y
tomar nota de lo que hace, cómo lo hace, la secuencia de pasos, los momentos y
las causas de porque toma decisiones. Esto ocurre en el lugar de trabajo mismo
del usuario y no en otro contexto. Es observar la realidad.
Ahora, el observador no debe ser mudo, dado que no aportaría gran valor. Este
método debe ser acompañado de una entrevista, o al menos una charla, para que
el observador corrobore su entendimiento y no suponga lo que ve.
Se puede avanzar aún más, si la tarea lo permite, al no comprometer recursos

o generar peligros, puede el mismo observador realizar la tarea con la ayuda
del “observado”. De esta manera lograr un conocimiento más acabado por la
práctica misma.
Como antes mencionamos lo mejor es que vaya acompañado de una entrevista

o que se utilice a posterior de la misma (o de una reunión moderada) como forma
de ampliar y verificar los requisitos recolectados.
Es un método que es aplicable casi únicamente a tareas repetitivas y con pocas

variantes. Tareas que requieran la toma de decisiones complejas donde hay
muchos aspectos a evaluar o las tareas que incluyen el uso de la creatividad
quedan fuera de su alcance o sus resultados no son los esperados dada la gran
complejidad a observar.
Su gran ventaja es la corroboración y la ayuda que brinda

a comprender los requisitos recibidos verbalmente. Las
desventajas que posee son su aplicabilidad a tareas
Atención simples y repetitivas y el gran consumo de tiempo que
requiere dedicar a la observación.

El desarrollo de software se realiza por lo general para dar soporte a un proceso
de negocios u es muy posible que el usuario al que observemos ya posea un
sistema con el cual soporte sus tareas, o puede que no. Ahora, si el usuario ya
posee un sistemas hay que tener en cuenta que esto puede inducirnos un sesgo
en el relevamiento. ¿Qué esto? Los usuarios de los sistemas tienden a resolver
las tareas de la forma que se los permite en sistema y no de la mejor forma
posible (por causas varias). Esto implica que el usuario no solo nos comente el
“como” realiza su tarea explicando lo que el sistema actual le permite realizar y
no explicando el “como” debería ser. Al realizar la Observación va a suceder
lo mismo, vamos a ver “cómo” lo hace y lo que vamos a ver es que lo
hace de esa manera porque es como el sistema actual lo deja hacer pero no
necesariamente va a ser lo mejor, lo correcto o lo deseable.
¿Qué implica esto? Que la observación debe estar acompañada de una

entrevista, como antes lo mencionamos, y esa entrevista debe cuestionar
cada paso al usuario para conocer si realmente vale la pena dicha acción.
Finalmente, podemos decir que es una técnica muy simple.
Para ampliar el contenido de este capítulo lea los siguientes

apartados que conforman la bibliografía básica una técnica
Leer derivada de esta: “La Etnografía”.
de Requerimientos. Apartados 4.5.5
Actividad 2: Una observación abierta
Propongo aquí una tarea “de campo” como lo es la

Actividad
Observación. Propongo que te acerques a un comercio,
por ejemplo, un supermercado y observes la actuación del
cajero. Toma nota, mental, de lo que hace previo a comenzar
a cobrar. Si es posible indaguemos los motivos.

Actividad 3: FORO - “Requerimientos ‘a distancia’ ”
Hoy en día es muy habitual en las organizaciones que existan
otras formas de comunicación más allá del “cara a cara” y del
Actividad
“teléfono”: mail, chat, videoconferencias, audioconferencias,
foros, escritorios compartidos.
Y es más notable la presencia de estos medios en

organizaciones dispersas geográficamente; estos medios de
comunicación han sumado muchos adeptos y se han hecho
habituales (y más aun con el costo de los viajes terrestres o
aéreos).
El chat es habitual con compañeros de trabajo, incluso

sentados a unos pocos metros de distancia. Estos medios
nos han aportado ventajas y desventajas: economicidad,
cierta pérdida de calidez, no poder escuchar una entonación,
rapidez…
Bien. El relevamiento de los requerimientos como una buena

práctica menciona el trabajo “cara a cara”.
Entonces, la idea de este foro es debatir sobre qué ventajas proporcionan

estas herramientas a las tareas de relevamiento, validación y análisis de
los requisitos; qué desventajas ocurren con las mismas y cómo podemos
salvarlas.
Los invitamos al foro mencionando ventajas y desventajas y posibles

soluciones a las desventajas. Comenten sus acuerdos/desacuerdos con
las opiniones de los demás participantes. Recuerden leer atentamente
cada intervención antes de realizar una publicación.
clase 5 Actividad 1: Vamos a planear una reunión moderada

claves de corrección Sin la formalidad del formato solo voy a mencionar los contenidos:
Preparación de la Reunión:
Facilitador: Juan Esteban Avila
Escriba: Carlos Alberto Quina
Dia y Horario: Martes 23/12/2017
Duración: 1 hs
Herramientas: Pizarra y fibrones

Agenda de temas a tratar:
Alta de una tarjeta
Habilitación de planes
Que planes se deben mostrar a los clientes
Que planes por cada producto
Promociones de los bancos
Durante la Reunión: (solo para un punto)

…
5- Promociones de los bancos:
El sistema recibe el código del banco, el código de la tarjeta, el rango
de numeración de la tarjeta, la fecha de inicio y de fin de la promoción, los planes
(cant. de cuotas + el % de interés), la zona geográfica donde es válida, el rango
de productos que se pueden vender con esa promo.
El sistema produce un ok o un fallo indicando si la promo pudo ser
cargada correctamente. También nos lista los productos alcanzados de manera
detalla y su precio final con la promo.
A priori no interactúa no otro módulo.
Una posible validación es la compra de un producto de $100 con
el plan de tarjeta OCA en 12 cuotas con 18,5% de interés. Debemos ver que lo
facture.
Actividad 2: Una observación abierta

No podemos poner una clave de corrección dado que es algo abierto. Asimismo
tenga en cuenta lo estudiado hasta el momento, y trate de observar todos los
detalles posibles.
clase 5
conclusiones Las dos técnicas nuevas que hemos visto nos ayudan a ampliar el espectro de
formas de realizar relevamientos. La primera, las Reuniones Moderadas logrando
orden y formalidad y la segunda le aporta una verificación de veracidad y una ayuda
a la comprensión de la misma. También conocimos otra técnica complementaria
llamada “Puntos de Vista” que nos permite descubrir los conflictos en los requisitos
surgidos de los distintos usuarios.

ANÁLISIS Y MODELADO DE REQUISITOS CON CASOS DE USO
clase 6
introducción
Lo que buscamos en esta clase es que comprendas qué es una especificación de
requerimientos y cómo analizar los requisitos para llegar a ella. Analizar significa
examinar detalladamente una cosa tratando sus partes por separado. El contenido
a analizar, todo lo relevado, por lo general es abundante y denso y esto lleva a
cometer ambigüedades, malas interpretaciones y omisiones. Precisamente esas
ambigüedades, malas interpretaciones y omisiones es lo que debemos eliminar
y reducir con el análisis y modelado para llegar a una especificación correcta. La
obtención de un documento de especificación va a permitirnos verificar con los
interesados la comprensión que tenemos de sus necesidades.
clase 6 La Especificación de Requerimientos

tema 1
Especificar un requerimiento es el proceso de dejarlos formalmente
documentados. Si bien las técnicas que vimos hasta ahora generaran
documentos estos son una ayuda para llegar a la especificación aunque pueden,
si es necesario, formar parte de la misma. A medida que vamos obteniendo los
requisitos podemos ir dejándolos asentados en un documento, la ‘Especificación’
(o SRS software request specification), que luego vamos a compartir con los
usuarios, los interesados y los restantes miembros del equipo de sistema.
La especificación tiene varios objetivos: debe servir como

base de entendimiento, y a la vez como declaración del
alcance del sistema a desarrollar y principalmente debe
Atención
servir como descripción del comportamiento del sistema.
Recordemos ahora un par de conceptos:
- Requisitos del Usuario: son los requisitos funcionales y no funcionales

que nos plantean los interesados. Especifican solo el comportamiento
externo (observable desde afuera) del sistema. Aquí no debe estar
presente el lenguaje técnico sino el lenguaje natural, tablas y gráficos
intuitivos.
- Requisitos del Sistema: estos requisitos extienden a los anteriores

y son el punto de partida para el diseño y desarrollo. Se agregan
muchos detalles, algunos ya del diseño propiamente dicho. Los
requisitos del Sistema también emplean lenguaje natural, tablas y
gráficos intuitivos, pero van más allá.

Y al ir más allá pueden incorporar:
- Lenguaje Natural Estructurado: se utiliza una plantilla estándar donde

cada campo del requerimiento ofrece información de un aspecto del
requisito.
- Lenguaje natural como si fuese un lenguaje de programación.
- Modelos gráficos: principalmente de UML, como el modelo de casos
de uso, el modelo de secuencia.
- Especificaciones matemáticas: principalmente utilizando la lógica y
la matemática discreta como la teoría de conjuntos y álgebra, sobre
todo si empleamos métodos formales de desarrollo.
El lenguaje Natural:
Es la herramienta más utilizada para la especificación de requerimientos,

es altamente expresivo y 100% intuitivo (dado que es nuestra forma
de comunicarnos) pero a la vez es altamente ambiguo. En la vida diaria
eliminamos la ambigüedad por medio de la charla, preguntando las dudas,
pero en las especificaciones esto no es posible, no podemos cuestionar a
un documento escrito. Tampoco es económico ni práctico ampliar el documento
hasta que tenga todas las posibles respuestas a todas las posibles dudas que
pudieran surgir, sería interminable y por lo tanto inmanejable. Este punto se
soluciona en parte con las metodologías ágiles y su expresión en el manifiesto:
“…hemos aprendido a valorar: Individuos e interacciones sobre procesos y
herramientas, Software funcionando sobre documentación extensiva… ”.
Lo podemos ampliar en http://agilemanifesto.org/iso/es/

Leer manifesto.html

A continuación les presentamos un ejemplo:
“Cuando estamos cobrando con Tarjeta de Crédito, si recibimos algún error

de parte de la tarjeta entonces lo debemos ver en la pantalla. Como si
estuviésemos cobrando con un posnet y sería bueno, que el sistema nos diga
cómo actuar en base a cada uno de estos mensajes. Por ejemplo: si nos
dice “SALDO INSUFICIENTE” – entonces el usuario debe rechazar el cobro
al cliente y solicitarle otro medio de pago. Pero si el mensaje es “SOLICITAR
AUTORIZACION – entonces, debemos llamar al emisor de la tarjeta y
comunicarlo con el cliente, y en ese momento el cliente solicita autorización
para realizar la transacción”
Lenguaje Natural Estructurado:

Esta técnica limita la libertad de expresión pero guía ayuda al especificador a
centrarse en lo importante y eliminar lo innecesario manteniendo la expresividad
del lenguaje natural.
La idea es utilizar una plantilla a completar con lenguaje natural pero con ciertos
campos predefinidos que abarcan los aspectos interesantes:
Por ejemplo: mostramos aquí una plantilla y la completamos con el ejemplo del
cobro con Tarjeta de Crédito.
Identificador: TC034 Descripción: Cobro con TC – Mensaje de Error

Función Responder a los mensajes de error devueltos por el sistema de cobro
Descripción Notificar al usuario de los mensajes, propios del sistema y los recibidos
desde el emisor de la tarjeta de crédito y darle una sugerencia de
acción
Entradas Respuesta a la transacción de cobro emitida por el emisor de la
tarjeta o resultado de validaciones internas o errores capturados por
el sistema
Fuente El webservice del emisor de la tarjeta
Salidas El código y el mensaje de error + la sugerencia de acción
Destino El usuario del sistema de cobro
Acción Si el código del error es numérico es devuelto por el emisor de la

tarjeta, si es alfanumérico es un error interno del sistema.
Requerimiento Luego de dos intentos de comunicación consecutivos si no obtenemos
un timeout y el código de respuesta es el mismo lo mostramos al
usuario
Precondición La conexión con el emisor debe estar activa
Postcondición La conexión con el emisor debe estar activa, el pago no debe estar
procesado.
Efectos Colaterales Ninguno
Autor: M. Bernarda
V1.3
Versión:
12/04/2016
Fecha:

El estándar IEEE830 como lectura ampliatoria:
El estándar “IEEE-STD-830-1998: ESPECIFICACIONES DE LOS REQUISITOS

DEL SOFTWARE” si bien fue superado por el estándar “iso-iec-ieee-29148-2011”
lo mismo es útil para entender los componentes de las especificaciones.
Lo invitamos a leer del estándar IEEE-STD-830-1998 para

hacer un refuerzo en las características de una buena SRS
Leer (Solicitud de Requerimientos de Sistema). Pueden ubicarlo
en: (https://www.ctr.unican.es/asignaturas/is1/IEEE830_
esp.pdf )
De esta norma rescatamos que los requisitos deben ser:
· Claros y concretos, sin imprecisiones ni ambigüedades, por ejemplo,

sin usar etcéteras, haciendo uso de listados taxativos.
· Concisos, debe explicar sin rodeos lo que se necesita.
· Completos, detallando todo lo que se necesita.
· Coherentes, no deben solicitarse en requisitos varios pedidos
contradictorios.

de Requerimientos. Apartados 4.3
Actividad 1: Practiquemos escribiendo especificaciones
La consigna de esta actividad es realizar una especificación

Actividad
en lenguaje natural estructurado, siguiendo la plantilla
mencionada anteriormente, a partir de una especificación
en lenguaje natural.

La especificación en lenguaje natural es la siguiente:
“Cuando un usuario, cualquiera que sea, va a utilizar el sistema debe primero

loguearse al mismo. Loguearse implica ingresar su usuario, previamente
entregado por el administrador del sistema, y su clave, la primera vez la clave
es 123456. Si el usuario no existe entonces el sistema debe mostrar el mensaje
“USUARIO INEXISTENTE” en el log de la parte inferior de la pantalla. Si el
usuario existe pero no coincide la clave entonces debe mostrar el mensaje
“CLAVE INCORRECTA” y si no se ingresó usuario, clave o ninguno de los
datos debe mostrar un mensaje en el log que diga “FALTAN DATOS”. Este
mensaje lo da el sistema luego que el usuario ingresa estos datos y presiona
el botón “Login”. El usuario puede, luego o antes o durante el ingreso de estos
datos presionar el botón “Cancelar” para que el sistema aborte el ingreso y
simplemente regrese al escritorio del S.O. Para que el usuario pueda acceder
al sistema entonces, es precondición que el mismo exista. Y luego del login el
estado del usuario debe ser “activo”, esto, porque antes del login en estado del
usuario debe ser “inactivo”. Si el usuario llegase a estar activo al querer hacer
login el sistema debe dar el mensaje “USUARIO YA ACTIVO, NO PUEDE
INGRESAR NUEVAMENTE”.
clase 6
ANALISIS Y MODELADO CON CASOS DE USO
tema 2
Nuestro objetivo en este tema es modelar los requisitos con la técnica gráfica de
Casos de Usos. Los diagramas de Caso de Uso muestran las relaciones entre el
sistema y su entorno.
Estás relaciones nacen de los requisitos planteados por el cliente pero no todos
los requisitos pueden ser expresados como relaciones entre el sistema y su
entorno.
¿Qué es un caso de uso? Vamos a hacer un repaso rápido del tema. Un caso de
uso puede tomarse como un escenario que describe lo que el usuario espera del
sistema. Contiene 3 tipos de elementos:
Actor -> es un rol que juega un usuario frente al sistema, también representa
otros sistemas y/o hardware. Gráficamente lo vemos así:

Caso de Uso -> es una operación que realiza el sistema tras una orden externa
o invocado desde otro caso de uso. Gráficamente lo vemos así:
Relación -> es la invocación de un caso de uso desde un actor o desde otro caso
de uso. Gráficamente lo vemos así:
Luego, por ejemplo, si queremos representar un caso de uso, donde el sistema

nos debe permitir cobrar con TC:
O algo más complejo, por ejemplo, representar el requisito de facturar, cobrar con
tarjeta de débito o en efectivo y descontar del stock:

Finalmente, nos da la posibilidad de representar gráficamente los límites del
sistema mediante una figura cerrada y transparente que envuelve a todos los
casos de uso que serán incluidos por el sistema.
Para profundizar en los diagramas y modelos de Casos de

Usos podemos recurrir a estos dos links:
Leer http://www-2.dc.uba.ar/materias/isoft1/2001_2/apuntes/
CasosDeUso.pdf
https://users.dcc.uchile.cl/~psalinas/uml/casosuso.html
Luego, una herramienta gratis para realizar diagramas es ‘Modelio’ que

podemos obtener desde http://www.modelio.org
Continuemos. Ahora, lo que observamos es solo un gráfico con un título, no un

detalle. Luego,

¿Qué ventaja tiene este diagrama?
· Visualizar y determinar los límites del sistema (su alcance, que

funcionalidades incluye).
· Permite mostrar gráficamente al usuario cómo será el sistema
y, por lo tanto, validar si incluimos todos los requerimientos
funcionales.
· El lenguaje (gráfico) utilizable es entendible por los usuarios.
¿Qué desventaja tiene?
· Deben completarse con información adicional que clarifique el

nombre de cada caso de uso.
· No permite modelar los requisitos no-funcionales.
Entonces, los casos de uso permiten analizar los requisitos (al listar y representar
dentro del modelo aquellos que son funcionales), nos permite relacionarlos
mostrando la dependencia entre ellos y nos permite validar los que hemos
entendido mostrando el diagrama al cliente, pero sin detalle de cada uno, es una
vista global.
Actividad 2: Los casos de Uso del Chef
1- Lea el siguiente enunciado:

Actividad

Estamos modelando los requisitos de un sistema de un restaurante. En una de
las entrevistas con los chefs nos mencionaron que suelen visitar al restaurante
críticos de comidas de algunos periódicos locales. Esta visita y la opinión de
los platos que expresan estos críticos en sus respectivos medios son muy
importantes para el restaurante. Por lo tanto, les interesa que el sistema lo
soporte. Indagando un poco más previo a armar un modelo de caso de uso el
analista consiguió los siguientes datos.
Los críticos de comida siempre llegan sin previo aviso. Ellos solicitan un
plato, prueban la comida y después la pagan, pero no llegan a consumirla
completamente. Eso sí, todos los platos que seleccionan van siempre
acompañados de vino, por lo tanto también ordenan y beben el vino, que se lo
dejan sugerir al chef.
En estos casos, la comida no es preparada por un ayudante de cocina, sino

directamente por el chef, para asegurarse siempre de una buena opinión del
cliente. A su vez, es el mismo chef quien sirve la comida al crítico.
- “Realmente, lo que nos interesa”, expreso el chef, - “es dejar asentado en el

sistema el plato y el vino que solicitó el chef, tomar su pago por la comida y
registrar que esos platos fueron cocinados por el chef directamente así como
que el chef es quien retiro el vino de la bodega en persona”.
- “¿Y la opinión que vuelca el crítico al día siguiente en los periódicos?”,
mencionó el analista.
- “no, la verdad no la dejamos asentadas en ningún lugar” por ahora no es
necesaria.
2- Arme un modelo de caso. El diagrama debe contener más de 5 casos de

uso, de los cuales solo 4 quedan dentro del alcance del sistema.

clase 6
Actividad 1: Practiquemos recibiendo especificaciones.
A continuación se ponen dos ejemplos en cada situación sobre cómo generar
ciudadanía organizacional pero los mismos no son exhaustivos, usted puede
haber elegido cualquier otra acción.
Identificador: TC035 Descripción:

Función Loguear los usuarios al sistema
Descripción Cuando un usuario desea acceder al sistema debe ingresar
su usuario y password y ser verificados por el sistema mismo
Entradas Usuario y Password

Fuente El usuario del sistemas
Salidas OK de ingreso o mensajes de error
Destino El usuario del sistema si es un mensaje de error o la vista
principal del sistema si es un OK
Acción Se valida contra la tabla users y la tabla pass, la segunda está

encriptada.
Requerimiento El mencionado en el enunciado
Precondición El usuario no debe estar logueado al sistema en otro equipo
Postcondición El usuario debe estar logueado al sistema en caso de ok, o
el usuario no debe aparecer como logueado en caso de falla.
Efectos Colaterales Ninguno

Autor: xxxxxxxxxxxxxxxxxxx
Versión: V1.1
Fecha: 12/04/2016
Actividad 2: Los casos de uso del chef

El diagrama al que se pretende llegar es el siguiente, puede tener variaciones
en el nombre y en los títulos.

clase 6
conclusiones Lo que hemos visto hasta el momento nos permite darnos una idea de los que
es el documento “Especificación de Requerimientos”, sobre todos basados en
la norma IEEE830. Y como toda especificación necesita de un trabajo previo,
conocimos la técnica del caso uso que nos permite analizar todo lo relevado
y determinar los límites del sistema, los comportamientos deseados y vamos
realizar. A su vez, la técnica de casos de uso es muy útil para comenzar a validad
los casos de uso.

clase 7
CLASIFICANDO Y VALIDANDO LOS REQUERIMIENTOS
introducción
En esta séptima clase vamos a adentrarnos en dos aspectos muy importantes, el
primero de ellos es la Clasificación de los requerimientos. La clasificación nos va
a permitir mantener ordenados y saber sobre que requerimientos trabajar.
Por otro lado, a los requerimientos necesitamos validarlos, saber que están
correctos, que reflejan lo que el usuario necesita, esta tarea muchas veces se
realiza en paralelo al relevamiento y/o al análisis en sí mismo.
clase 7 Clasificación y Organización de los Requerimientos

tema 1
Por un momento dejemos de lado las técnicas de descubrimiento, recuperación
y análisis de requisitos que hemos visto y volvamos a un concepto teórico. Los
requisitos deben ser clasificados y ordenados.
Si bien podemos haber realizado los relevamientos empleando las técnicas vistas
en las clases 3 a la 6 de manera ordenada también podemos haberlo hecho de
manera desordenada.
Podemos haber llegado a este punto con una simple compilación de requisitos,
solo un agregado de requisitos.
Pero ¿cómo ubicamos dentro de la misma los requisitos? ¿Es una compilación
que sigue algún criterio o es simplemente una agregación de requisitos?
Clasificar significa dividir individuos que pertenecen a un

grupo según ciertos criterios. Primero, los “individuos”
son los requisitos que hemos relevado. Ahora, para poder
trabajar con ellos debemos ‘indexarlos’ (si empleamos
un término informático), o dicho de manera más plural
debemos ‘clasificarlos’. Existen muchos criterios, o
Atención
conjuntos de ellos, que se pueden emplear para llevar
adelante la tarea. Dos de los más habituales son la
pertenencia a un módulo del sistema y la pertenencia a
un proceso de negocio de la organización.
Organizamos los requisitos y su posible modelado y otros entregables/documentos

agrupándolos según el criterio o criterios seleccionado.

· Arquitectura del Sistema: asociamos los requisitos a los módulos que
conforman el sistema (al menos a los módulos planeados). Facilita
el trabajo del desarrollo al agrupar las funcionalidades por módulos.
· Proceso de Negocios: asociamos los requisitos a los procesos de
negocio de la organización. Facilita el trabajo de los analistas ya que
obtienen una visión completa del proceso.
Luego de clasificados los requisitos deben organizarse. Esto es priorizarse

dentro de cada una de las clasificaciones. Lo hacemos ordenándolos desde el de
mayor prioridad al de menos prioridad. Darle este peso no es tarea sencilla, es
una tarea extremadamente compleja y fácilmente dispara conflictos dentro de la
organización misma.
¿Por qué surgen estos conflictos? Básicamente, por la escases de los recursos
de desarrollo que impiden desarrollar el 100% de lo deseado en el tiempo
deseado. Luego, distintos usuarios e interesados pugnan porque su parte se
desarrolle antes que otras partes del sistema.
Entonces, muchas veces, los conflictos escalan en la jerarquía de la organización

y terminan siendo resueltos por los altos niveles. Esto en hasta cierto punto es
correcto y hasta cierto punto incorrecto. Cuestiones del sistema que corresponden
al día a día no deben escalar, ya que no son de interés de la dirección, por el
contrario, cuestiones del próximo módulo o del próximo proceso a desarrollar si
deben escalar ya que seguro son parte de una estrategia más abarcativa.
Existen muchos criterios para organizar los requisitos. Un posible set de criterios
para requisitos de un alto nivel (un módulo en un sistema y no un color del rótulo
de un campo) puede ser, para dicho requisito y para aquellos que compiten con
él en las fechas determinadas.
Para ordenarlos, por cada uno de ellos podemos completar los siguientes datos:
1. Volumen de Ventas o Monto de los Ingresos x ventas

2. Mejora la experiencia del usuario
3. Mejora la experiencia del cliente (que puede o no ser el mismo que el
usuario)
4. Ahorro de costos (en $)
5. Fidelización de los clientes (en $)
6. Esfuerzo de desarrollo (en meses u hs. hombre)

Ahora, aun así, puede que estos datos sean subjetivos, estimados o simplemente
inventados lo que llevaría un orden que no necesariamente sea el válido, por
lo que es necesario ser lo más certeros posibles y tratando siempre de utilizar
números verdaderos para cada punto.
Avancemos un poco más, ¿Qué técnica podemos utilizar para clasificar y ordenar
los requisitos? Una muy útil son los Mapas Mentales.
Los mapas mentales son diagramas que sirven para

representar de manera creativa conceptos conectados.
La idea en ellos es representar los conceptos claves y
sus conexiones claves. Con agregados como Notas,
Imágenes, Tablas, Sonidos, Atributos según el software
utilizado. Como principales ventajas vamos a mencionar:
Atención
· Ayuda a tener claridad de los componentes de
un tema (a analizar)
· Ayuda a conocerlo de un vistazo (a analizar)
· Facilitan el análisis de temas complejos
Ejemplo de la estructura de un mapa mental
Existen muchas herramientas para implementar la técnica de Mind mapping.

Por ejemplo: FreeMind, cuyo sitio es http://freemind.sourceforge.net/wiki/index.
php/Main_Page.

de Requerimientos. Apartados 4.5 y 4.7

Actividad 1: ¿Mapas mentales? ¡Allá vamos!
Vamos a retomar el diálogo presentado en la clase 3-Tema

Actividad
2, como ejemplo de una entrevista.
A partir de la entrevista, debe extraer requerimientos y
clasificarlos en un mapa mental
Ejemplo: estamos preguntando a los vendedores como realizan hoy en día el cobro
con tarjeta de crédito para darle soporte con el sistema, digamos, realizar un posnet
que funcione en la PC y descubrir mejoras. Hay dos participantes: E – entrevistador y
F – usuario:
E – contame, que pasos seguís para cobrar al cliente cuando te manifiesta que quiere
pagar con tarjeta.
F – bueno, yo le paso la tarjeta por el posnet y luego cargo el cupón en el sistema.
E – ¿Cargas el cupón? ¿Qué viene siendo? Lo escaneas y el sistema guarda la
imagen ¿?.
F – noooo, solo cargo el nro. Cuando el sistema va a emitir la factura.
E – bien, tomo nota, ahora, que datos ingresas en el posnet.
F – se ingresa el monto, los últimos 4 dígitos de la factura y se selecciona el plan de
pagos, o sea, las cuotas.
E – y esas cuotas, ¿las ingresas a mano? ¿son libres? ¿o las elegís de una lista?
F – las elijo de una lista, cada tarjeta tiene distintas cantidades de cuotas, según el
convenio con el banco.
E – OK, perfecto. Y las tarjetas ¿recibimos todas las que hay?
F – no, no todas, es como las cuotas, según las que estén dentro del convenio con los
bancos.
E – y que pasa si tratas de cargar una que no está en el convenio?
F – no se puede, el sistema no te deja
E - ¿no te deja? ¿Cómo es eso?
F – simplemente no está para elegirla
E – ahh ahora sí, hay un listado de tarjetas vigentes y cuando elegís una te muestra las
cuotas posibles.
F – Claro! Es así. Y te agrega un dato más, muestra también el intereses, ponele, vos
elegís VISA 18 cuotas y te dice 3% de interés.
E – ¿y te sirve que sea así? ¿Es cómodo? ¿Es rápido?
F – y… no, el listado de tarjetas no está ordenado, y las tarjetas se repiten, solo que se
le agrega el banco emisor al lado. Esto es porque a veces, la misma tarjeta, la misma
cantidad de cuotas, para dos bancos distintos, tiene distinto interés, o por ahí una tiene
una promo con 0% interés.
E – Fantástico, tiene que estar ordenado, ¿y cómo es mejor? ¿Alfabéticamente?
F – No, mira, el 80% de las compras se hace con 3 tarjetas distintas, con que esas 3
estén primeras es suficiente.
…

clase 7 TEMA 2. VALIDACION DE REQUERIMIENTOS
tema 2
Analizar los requerimientos no solo es clasificarlos y priorizarlos, sino también
validarlos, que en cierta forma lo hemos venido haciendo obligados al aplicar
técnicas como el modelado de caso de uso.
Para ir introduciéndonos en el proceso, los grandes pasos a realizar para llegar a

los requerimientos especificados son:
Basado en Ian Sommerville, Ing. de Software 9° Edición
Prestemos atención a que no es un proceso con un final, sino un ciclo continuo.

Debemos revisar las especificaciones (más aun estando en un proceso de
desarrollo ágil). Más adelante en la materia retomaremos este proceso y
lo ampliaremos, por ahora lo usemos solo para ir organizando y ubicando los
conceptos hasta ahora vistos.
Regresemos a la “Validación” de los requerimientos, la idea es verificar que los

requisitos definan lo que los interesados realmente quieren. Es una actividad que
es parte o al menos que se realiza en paralelo con el análisis de los requisitos.

La validación de requisitos debe realizarse sobre 5
aspectos de los mismos:
1- Validez. La idea es asegurarse que una
funcionalidad requerida por un interesado es
válida para los restantes. Debemos asegurarnos
que todos los interesados están de acuerdo con
la misma.
2- Consistencia. Esto es asegurarnos que no haya
conflictos y contradicciones entre distintos puntos
de los requerimientos.
3- Totalidad. Se deben definir todas las funciones y
las restricciones pretendidas por los interesados.
Atención
4- Realismo. Debemos asegurarnos que la
tecnología, el presupuesto y el tiempo asignados
nos permitan cumplir con los requisitos.
5- Verificabilidad. Para eliminar potenciales disputas
cuando el software fue entregado y para poder
establecer un criterio de fin debemos escribir cada
requisito de forma tal que podamos obtener una
prueba objetiva para indicar que se cumplió y que
se finalizó.
Ejemplifiquemos cada uno de ellos, si bien son simples, para tener una mejor
comprensión.
1- Validez. Supongamos un caso, por ejemplo, muy trivial, pero frecuente.

Nos hallamos dentro de una gran organización dedicada el retail. Su
sistema de facturación imprime en impresoras laser las facturas del
cliente. El último año el costo del toner y del papel alcanzó valores
insostenibles, el área de finanzas requirió un ahorro drástico de papel y
de impresión. Mientras relevábamos sus requisitos para el nuevo sistema
de facturación nos pidieron eliminar las notas legales al final de la factura,
aquellas notas que indican por ejemplo, los datos de comunicarse a
Defensa del Consumidor. Pero, este requisito no es convalidado con el
área de legales, quien exige que se continúe mostrando, dado que por
ley en varias provincias debe aparecer. Luego, es un conflicto, el pedido
válido para un interesado no es válido para otro, y se debe llegar a un
acuerdo con ambos.

2- Consistencia. Supongamos el mismo sistema de facturación del ejemplo
anterior, pero ahora respecto de la manera de referencias las sucursales
de cadena de retail. El sector de facturación quiere que cada factura
mencione como identificador de la sucursal los 4 primeros dígitos de las
facturas concatenados a la calle y altura, ejemplo: “0001COLON1425”.
Pero, el área de finanzas solicita que en los reportes el identificador de las
sucursales sea el nombre interno con el que se maneja la organización,
por ejemplo: “CORDOBA-01”. Esta inconsistencia en la definición de las
sucursales puede llevar a confusión.
3- Totalidad. Continuemos con el mismo ejemplo. Es impensable que el

sistema de facturación de la cadena de retail no tenga un reporte del
IVA. Si el mismo faltara, porque, por ejemplo, no fue solicitado por
los interesados, estaríamos ante un problema en la totalidad de los
requisitos, dado que realizar la tarea manualmente sería más costosa
que el desarrollo mismo y dado que los datos para armar el reporte están
en el sistema mismo.
4- Realismo. En este punto los ejemplos pueden quedar desfasados por el

paso del tiempo, pero suponiendo los ejemplos anteriores, hace unos 15
años, abonar una compra por medio del teléfono celular hubiera sido un
caso de realismo dado que no estábamos preparados para ello, pero hoy
en día ya no lo es.
5- Este punto es especialmente importante, dado que es el límite al trabajo,

y este punto va de la mano de manera muy estrecha con el anterior, el
del realismo. Supongamos el ejemplo anterior: el sistema de facturación
debe emitir la factura en papel o de manera electrónica y enviársela al
cliente por mail en el momento. Hoy en día es realista. Pero, ¿cuál es el
punto en el cual damos por cumplido el requisito? El requisito mismo debe
mencionarlo: “daremos por cerrado este requisito cuando: a. la factura
versión electrónica se envíe por medio del sistema de correo electrónico
de la organización, por medio de SMTP, y la misma sea una copia fiel
(formato y datos) de la versión papel especificada en el requerimiento
4.5 del presente documento”. Si esto se cumple, el requisito se da por
satisfecho.

Leer
Actividad 2: Validando Requisitos
El siguiente ejercicio no tiene una respuesta cerrada, para

Actividad
ello deberá poner en juego su creatividad y lo estudiado
hasta el momento.
1- Lea el texto que se le propone
2- A partir del texto de un requisito Ud. debe completar
el siguiente cuadro explicando si cumple o no cada
punto y si no lo cumple justificando:
Cuadro:
¿Es válido? ¿Es consistente? ¿Es total? ¿Es real? ¿ E s

verificable?
Si lo cumple
Justificación

Texto del requisito:
“El sistema debe mostrar el stock disponible de los ítems a la venta en cada
sucursal. Cada sucursal tiene un stock propio. Desde una sucursal se puede
‘reservar’ un ítem en alguna de las otras sucursales, pero, solo para ser retirado,
la venta se concreta en la sucursal origen. El sistema debe informar, antes de
concretar la venta, si el elemento a vender está disponible en esta sucursal y
en qué otras sucursales está disponible. El cliente debe optar donde lo retira.
Cada sucursal tiene dos parametrizaciones sobre los elementos en stock, una
que es el stock mínimo y otra que es la cantidad “guardada” para reservas
(solicitada por el jefe de una sucursal). El gerente de ventas menciona que
no debe existir una cantidad ´guardada´ para reservas, sino que debe poder
reservarse todo el stock, salvo el mínimo. Indagando esto se da porque
sobre cada venta se cobra una comisión, la cobra la sucursal que vende, y si
una sucursal disminuye su stock cobra menos comisiones. Vamos a dar por
finalizado este requerimiento cuando el sistema muestre la cantidad en stock
de la sucursal en donde se realice el trámite y la cantidad en cada una de las
otras sucursales”.

clase 7 Actividad 1: ¿Mapas Mentales? ¡Allá vamos!
El mapa mental para clasificar y ordenar los requerimientos puede ser así:
Atención, solo la rama de “Crédito” es válida, la otra esta agregada para ubicarnos
en el contexto.

Actividad 2: Validando Requisitos
Una posible opción de la tabla es la siguiente:
¿Es válido? ¿Es consistente? ¿Es total? ¿Es ¿Es

real? verificable?
Si lo cumple NO NO SI SI SI
Justificación Porque hay Porque define dos
necesidades parametrizaciones
encontradas distintas sobre lo
entre dos mismo
interesados
clase 7 Es importante tener en cuenta que la validación de requisitos es fundamental.

conclusiones Nos permite asegurarnos que vamos a realizar el trabajo necesario sin tener que
luego rehacer, o al menos vamos a disminuir ese rehacer. Y por supuesto, para
asegurarnos que sean los correctos.
Ahora siempre antes de validarlos tenemos que tener los requisitos organizados,
clasificados, para entenderlos correctamente, para tener un mapa mental de los
mismos.

clase 8 REQUERIMIENTOS DURADEROS Y VOLATILES
introducción
Como usted verá a lo largo de la clase existe otra clasificación de los requerimientos
que es muy importante: los requerimientos que son duraderos y los volátiles. La
principal característica que los ubica en una u otra categoría es su predisposición
a cambiar rápidamente. Es importante tenerlos identificados porque esta
predisposición al cambio implica cambios en el proyecto de desarrollo mismo, lo
que implica más tiempo y reserva de recursos.
Por otra parte, en la 2° parte de la clase veremos una técnica más de validación
de los requisitos, que consiste en contrastarlos contra los procesos de negocio
previamente modelados con BPMN o Diagramas de Flujo.
clase 8
Requerimientos duraderos y volátiles
tema 1
Los requisitos cambian con el tiempo, durante el mismo proyecto de
desarrollo y a posterior, los sistemas no son estáticos en el tiempo, deben
evolucionar con el negocio (u organización misma) y más aun dependiendo
del contexto en el que se halla la organización misma. Supongamos un sistema
que da soporte a una empresa de tecnología, la velocidad de evolución de
la tecnología es muy alta comparado por ejemplo con un sistema para una
organización religiosa basada en dogmas estables en el tiempo (expresado solo
a modo de ejemplo para entender el concepto, no por ser 100% cierto).
Este cambio de los requisitos debe gestionarse si o si

durante el proyecto de desarrollo del software y a posterior
durante la vida útil del sistema sino implicaría que el
Atención sistema ya no satisfaga las necesidades del usuario y
quede de lado.
Por otro lado, los requisitos pueden cambiar también a medida que vamos
ganando comprensión de las necesidades mismas de los usuarios, desde el
lado del equipo de desarrollo, y al revés, a medida que el usuario va ganando
comprensión del sistema y de sus potencialidades. En resumen, hay tres fuentes
de cambios: los cambios del negocio al cual da soporte el sistema, los cambios
en la comprensión de este negocio y los cambios en la comprensión del sistema
y el potencial de la tecnología de desarrollo.

Ahora, cambios de los requisitos implican desarrollar código. Esto implica tiempo,
personas, dinero, consumo de recursos. Los proyectos por lo general implican
varios años de desarrollo, tiempo suficiente para que se expresen esos cambios
y durante esos años, estas evoluciones deben ser gestionadas.
Para el análisis de los requerimientos es fundamental clasificar a los requerimientos

en dos tipos:
- Los duraderos
- Los volátiles
¿Por qué? El desarrollo de los requisitos duraderos nos asegura que el software
desarrollado para ellos es útil y lo va a seguir siendo por un tiempo sin disponer
de esfuerzo extra. En cambio el desarrollo de los requerimientos volátiles
implican más esfuerzo dado que es necesario validarlos nuevamente (y volver
a relevarlos) justo en el momento previo a su desarrollo y acercándonos al final
del desarrollo del sistema completo por eventuales correcciones.
De manera más formal, decimos que los requerimientos duraderos son aquellos
relativamente estables y que pertenecen al núcleo del proceso de negocio de
la organización. Y los volátiles son aquellos susceptibles de cambio durante el
desarrollo o una vez puesto en producción el sistema.

A su vez, Harker and others (Harker et al., 1993) sugiere una clasificación de
los requerimientos volátiles:
· Mutables: son aquellos que cambian a causa de cambios en el entorno

en donde se desarrolla la organización. Por ejemplo, para una empresa
de telecomunicaciones cambios impuestos por el órgano de regulación
de la actividad.
· Emergentes: son aquellos que nacen de la comprensión, del sistema y
del potencial de la tecnología de desarrollo, por parte del usuario. Por
ejemplo, en un sistema de facturación el usuario decide disponibilizar
la factura en la web.
· Consecuentes: son aquellos que nacen como consecuencia de la
introducción del sistema en la organización. Por ejemplo: la introducción
de una pantalla para otorgar turnos para ser atendidos por los médicos
de una clínica implica que la secretaria obtenga un listado de los turnos
dados para organizar los calendarios de los médicos.
· De compatibilidad: son aquellos que nacen para mantener la
compatibilidad de los sistemas con los cambios de los procesos
mismos de la organización. Por ejemplo: un proceso de venta de un
producto muy caro a crédito a cargo de una empresa requiere que la
empresa misma valide la identidad del cliente para que no caiga dentro
de posibles fraudes, pero, al principio del desarrollo esta validación de
identidad no existía, la empresa ha implemento a mitad del desarrollo.
La validación de identidad consiste en ejecutar una serie de preguntas
que deben ser correctamente respondidas por el cliente previamente a
retirar el producto comprado desde el almacén.
Luego, ¿para qué nos serviría entonces analizar y clasificar los requisitos en
duraderos y volátiles? Como antes mencionamos, los duraderos pueden ser
los primeros en ser trabajados dado que sabemos que van a ser estables en
el tiempo y una vez conseguidos no nos requerirán esfuerzo extra. Por otra
parte conocer los volátiles es útil para revalidarlos de manera continua con el fin
de conseguir que siempre se mantenga vigente (con los cambios apropiados)
para que el trabajo de desarrollarlos no haya sido en vano por haber quedado
desactualizados.

Pearson Educación. México. 2011. - Capítulo 4 – Apartado
Web
https://ifs.host.cs.st-andrews.ac.uk/Books/SE9/Web/
Requirements/EnduringReq.html

Actividad 1: Descubrir requisitos duraderos y volátiles
Lea los siguientes requisitos, indique por cada uno si lo

Actividad
considera duradero (marcándolo con una “D”) o volátil
(marcándolo con una “V”). Justifique.
Los requisitos corresponden al sistema de envíos de pedidos

de delivery de una empresa de venta por internet:
1- Los pedidos siempre son despachados por correo,

nunca por medio de comisionistas o empresas de
bus. Tipo: ____
2- El costo de los envíos es $180,00 a cualquier parte
del país. Tipo: ____
3- Requerimos que se especifique la dirección de
destino y los datos de la persona que recibirá el
paquete. Tipo: ____
4- El cliente puede, si lo desea, realizar el seguimiento
del paquete por medio de la web de la empresa.
Tipo: ____
Modelado de un Proceso de Negocios con BPMN

clase 8
tema 2 En este punto nos alejamos un poco de los requisitos en sí mismos pero nos
acercamos a una técnica que nos permite ayudar a validar si lo requisitos
se adecuan al proceso de negocios y si nuestro entendimiento es correcto.
Consiste en modelar el proceso de negocios con una de dos técnicas:
1. Diagramas de Flujo
2. BPMN
Un proceso de negocios en un conjunto de actividades que producen un resultado.

Estas actividades están bien diferenciadas unas de otras. Representan el COMO
se hace y no el QUE se hace, el QUE sería el resultado del proceso de negocios.
Al realizar un modelo del proceso de negocios modelamos el COMO. Este COMO

son actividades susceptibles de ser soportadas por un sistema informático.

Entonces, este modelo nos permite verificar los requisitos,
contra una fuente distinta a los mismos usuarios (si el
proceso ya existía modelado). O si sólo podemos modelar
los procesos desde el usuario mismo que nos planteó los
requisitos podemos utilizarlos como un lenguaje común
Atención
y formal del proceso de negocios, lo que al eliminar la
subjetividad, nos permite validar los requisitos con más
seguridad.
Existen muchos métodos para modelar los requisitos, BPMN, Diagramas de flujo,
YAWL entre otros.
Veremos dos ellos rápidamente y tendremos el link a donde ampliar el tema.
BPMN - Business Process Modeling Notation
Es una notación gráfica de los procesos de negocio que tiene como objetivo
ofrecer un estándar para el modelado legible para todos los involucrados en un
proceso. BPMN es similar a los diagramas de flujo de datos pero no es lo mismo,
no modela los flujos de los datos, modela el avance del proceso.
Contiene 4 categorías de elementos para modelar:

1. Objetos de Flujo: eventos, actividades y compuertas
2. Objetos de Conexión: flujo de secuencia, flujo de mensajes,
asociaciones
3. Carriles
4. Artefactos: objetos de datos y anotaciones
Cada uno de los pasos del proceso se representa con un símbolo y estos se
secuencian con conexiones de secuencia y flujo de mensajes.
Existen tres elementos básicos que describen el comportamiento del proceso: las
tareas, los eventos y las compuertas. Queda fuera del alcance de esta clase el
explicar por completo BPMN, por lo que recomiendo profundizar la metodología
aquí http://www.bpmn.org/
Por ejemplo, en la figura 1 observamos un pequeño diagrama de BPMN donde

a partir de la ocurrencia de un evento se dispara el proceso. La primera tarea
es en base a algunos datos del evento definir una acción, con el resultado de la
misma se toma una definición: cuál es la próxima tarea, que puede ser ‘tarea 2’
o ‘envió de notificación’. Al finalizar aquella de estas dos acciones que se haya
disparado, el proceso de negocios termina. La tarea definir acción tiene asociado
un objeto de datos de entrada que representa los datos que ingresan al proceso
y que luego se usan para definir la acción a tomar.

Figura 1 – un pequeño modelo de un proceso de negocios.
¿Y cómo nos ayuda a validar un requisito? Aunque es un ejemplo muy trivial es

ilustrativo, supongamos que el requisito no plantea tres acciones a seguir y en
proceso de negocios modelados solo tenemos dos, eso nos dispara una alerta.
Dicho de otra manera, debemos verificar que cada requisito se adecue al modelo
del proceso de negocios y de no ser así verificar cual de ambos no es correcto.
Atención, las actividades pueden ser manuales o automatizadas (o realizadas por
un humano o por un sistema); ambas pueden participar de un requisito,
Sugerencia de lectura: Análisis de BPMN ic 1 http://

revistasum.umanizales.edu.co/ojs/index.php/ventanainformatica/
article/viewFile/274/397
Leer Obtenido de la biblioteca de revistas de la Universidad de
Manizales de Colombia. Revista “Ventana Informática” Nro.
30 de Junio de 2014.
Diagramas de Flujo
Son similares a los diagramas de BPMN, pero más generales, no solo enfocados
a procesos de negocio. Son, como en el caso anterior, la representación gráfica
de un algoritmo o un proceso dividido en pasos, pero es menos expresivo que un
BPMN dada su alta generalización que le hace perder precisión. Lo mismo son
útiles para modelar un proceso de negocio que nos sirva para verificar luego los
requisitos.

¿Y cuál sería la ventaja de un Diagrama de Flujo respecto de un Diagrama de
BPMN? Es aún más intuitivo y requiere menos aprendizaje por parte del usuario.
Los diagramas de flujo son una versión de los Diagramas de Flujo de Datos que
se utilizan en informática pero con algunas modificaciones:
- No modelamos el flujo de datos sino la secuencia de actividades

- Usamos solo algunas de las formas:
o Ovalo para denotar inicio y fin del proceso
o Cuadrado o Rectángulo para denotar una actividad
o Rombo para denotar una toma de decisiones.
Las formas a utilizar básicas que mencionamos (óvalo, cuadrado y rombo) no

son las únicas a utilizar, puede ser mejorado agregando otras con significado
especial. Dicho en otras palabras no es rígido.
Como ejemplo de un diagrama de flujo de actividades modelo el mismo caso del

BPMN anterior:

Observemos que aquí no podemos modelar los Objetos de Datos, es un caso de
pérdida de expresividad entre ambos lenguajes gráficos.
Actividad 2: Modelar un proceso en BPMN
Luego de leer la sugerencia de lectura de BPMN se les

Actividad
solicita modelar el proceso descripto en el siguiente requisito:
“El proceso es simple, se dispara cada vez que se carga un pedido

de delivery, la primera tarea que se realza es recolectar los datos del
mismo son el material a entregar, el domicilio de entrega y el receptor
del pedido (nombre + dni). Si el domicilio de entrega se halla fuera de
provincia donde está la sucursal donde se realizó la compra entonces,
se dispara una notificación vía mail al cliente. Si por el contrario se
encuentra en la misma provincia, entonces se procede a empaquetar
y despachar de inmediato el paquete, tarea en la cual se agrega a los
datos del pedido el nro. de guía del correo”.
Clase 8 ic 1
información
complementaria

Universidad de Manizales Facultad de Ciencias e Ingeniería
Análisis de BPMN como

herramienta integral para el
modelado de procesos de negocio*1
>$QDO\VLVRI%301DV,QWHJUDO7RROIRU
%XVLQHVV3URFHVV0RGHOLQJ@
JUAN FEDERICO GÓMEZ ESTUPIÑAN2
RECIBO: 20.11.2013 – APROBACIÓN: 08.04.2014
Resumen
El objetivo del artículo es caracterizar el estándar Business Pro-
FHVV0RGHODQG1RWDWLRQ%301FRPRKHUUDPLHQWDJUi¿FDSDUD
el modelado de los procesos de negocio de una organización, y
realizar un análisis crítico de las posibilidades que ofrece, iden-
WL¿FDQGR VXV YHQWDMDV \ GHVYHQWDMDV SDUD UHSUHVHQWDU DGHFXD-
GDPHQWHDVSHFWRVFRPRDFWRUHVDFWLYLGDGHVHYHQWRVÀXMRVGH
WUDEDMRFRQWUROHV\UHFXUVRVHQWUHRWURV3DUDYHUL¿FDUODIXQFLR-
nalidad que ofrece BPMN, se usó como caso de estudio ‘Alquiler
de Vehículos’, que incluye los procesos básicos de compra,
gestión, alquiler y venta de vehículo. Se encontró que la versión
BPMN 2.0, incluye un conjunto de prestaciones adicionales que
permiten modelar en forma completa y precisa los procesos de
negocio, condición necesaria para que a partir de estos modelos
se pueda implementar correctamente el sistema de gestión de
procesos de negocio, utilizando una herramienta válida para tal
¿Q6HFRQFOX\HTXH%301HVXQDKHUUDPLHQWDVHQFLOODIiFLOGH
* Modelo para la citación de este artículo:

GÓMEZ ESTUPIÑÁN, Juan Federico (2014). Análisis de BPMN como herramienta integral
para el Modelado de Procesos de Negocio. En: Ventana Informática No. 30 (ene-jun). Mani-
zales (Colombia): Facultad de Ciencias e Ingeniería, Universidad de Manizales. p. 9-25. ISSN:
0123-9678
1 Reporte de caso proveniente del proyecto Construcción de un Proceso de Desarrollo de
Software con Base en Model Driven Architecture MDA, Model Driven Software Development
MDSD y Business Process Management BPM, ejecutado en el periodo marzo de 2010 a
Julio de 2013, e inscrito en el Grupo de Investigación en Procesos y Calidad de Software
GIPROCAS, adscrito al Programa de Ingeniería de Sistemas de la Universidad de Boyacá.
2 Ingeniero de Sistemas, Especialista en Telemática, MSc(c) en Ciencias de la Información y
las Comunicaciones. Docente investigador y Jefe del Centro de Informática de la Universidad
de Boyacá (Tunja, Boyacá, Colombia). Correo electrónico: jfgomez@uniboyaca.edu.co

Nº 30 - enero - junio / 2014
comprender, pero con una gran potencialidad para el modelado

de procesos de cualquier tipo de organización.
Palabras Clave: Business Process Management BPM, Business
Process Model and Notation BPMN, Alquiler de Vehículos, Busi-
ness Process Management Suite BPMS.
Abstract
The aim of this paper is to describe the standard Business Process
Model and Notation BPMN, graphic tool for modeling business
processes of an organization, and critical analysis of the possi-
bilities, identifying advantages and disadvantages to adequately
UHSUHVHQWDVSHFWVDVDFWRUVDFWLYLWLHVHYHQWVZRUNÀRZVFRQWUROV
and resources among others. To verify the functionality offered
BPMN, is used as a case study ‘Rent a Car’, which includes the
basic processes of acquisition, management, leasing and sale of
vehicle. We found that this standard, particularly BPMN version
2.0, includes a set of additional features that allow you to model a
complete and accurate business processes, necessary condition
for that since these models are able to successfully implement
the business process management system, using a valid tool for
this purpose. We conclude that BPMN is a simple tool, easy to
understand, but with a great potential for modeling processes of
any type of organization.
Keywords: Business Process Management BPM, Business Pro-
cess Model and Notation BPMN, Rent a Car, Business Process
Management Suite BPMS.
Introducción
/DVRUJDQL]DFLRQHVSDUDPDQWHQHUVHFRPSHWLWLYDVDGHPiVGHVHUH¿-
FDFHV\H¿FLHQWHVGHEHQVHUiJLOHVHQODDGDSWDFLyQGHVXVSURFHVRVGH
negocios a los cambios que se generan en el entorno y que tengan que
ver con sus objetivos. A este propósito fundamental apunta la gestión
de procesos de negocio (Business Process Management, BPM), como
disciplina integradora de las capas del negocio y la capa tecnológica
para la gestión empresarial por procesos.
BPM es un enfoque novedoso que ha venido adquiriendo importancia
en las organizaciones. Incluye un conjunto de mejores prácticas de
gestión de procesos, herramientas y tecnologías utilizadas para diseñar,
representar, analizar y controlar todo lo relacionado con los procesos del
10

QHJRFLR7LHQHFRPRSURSyVLWRIXQGDPHQWDOGH¿QLUSURFHVRVGHQHJRFLR
rápidos, efectivos y transparentes a toda la organización.
La implementación práctica de los fundamentos de BPM, se hace me-
diante una suite de gestión de procesos de negocio (Business Process
Management Suite, BPMS), que es un sistema que integra en un en-
WRUQRJHQpULFRODVIXQFLRQHVGH¿QLGDVSRU%30SHUPLWHODLQWHJUDFLyQ
de los procesos manuales y automáticos en toda la cadena de valor
de la organización.
Business Process Model and Notation, BPMN, es una herramienta grá-
¿FDHVWDQGDUL]DGDSDUDHOPRGHODGRGHSURFHVRVGHQHJRFLR'H¿QH
un lenguaje sencillo, comprensible, que puede ser utilizado por personal
no técnico particularmente los analistas de negocios y por profesionales
de múltiples disciplinas, es decir, no es para uso exclusivo del área de
TI. BPMN es un lenguaje común que tiene como propósito reducir la
brecha de comunicación que se presenta entre el diseño de los proce-
sos de negocio y su implementación. Aunque BPMN utiliza un formato
GHÀXMRGHWUDEDMRHVPXFKRPiVTXHXQDKHUUDPLHQWDSDUDHODERUDU
GLDJUDPDVGHÀXMRGHGDWRV
El artículo presenta inicialmente los antecedentes de BPM, la relación
entre BPM y la arquitectura orientada a servicios (SOA), la suite de
gestión de procesos de negocio (BPMS), y BPMN como herramienta
JUi¿FDSDUDPRGHODGRGHSURFHVRVGHQHJRFLR/XHJRVHGHVFULEHOD
metodología utilizada en el proyecto de investigación, particularizando
en la aplicación de BPMN para el modelado del caso de estudio utili-
]DGRTXHHVHODVSHFWRHVSHFt¿FRKDFLDGRQGHVHHQIRFDHODUWtFXOR
Finalmente, teniendo en cuenta los resultados obtenidos en la aplicación
de BPMN y los planteamientos de otros autores, se presenta el análisis
de BPMN como estándar para el modelado de procesos de negocio.
1. Antecedentes
$FWXDOPHQWHODVHPSUHVDVDGHPiVGHVHUH¿FLHQWHV\H¿FDFHVUHTXLH-
ren adaptarse rápidamente a los permanentes y frecuentes cambios en
su entorno, impulsados entre otros aspectos por la globalización. Aque-
llas que lo logran obtienen más ventajas competitivas,lo que se traduce
en posicionamiento, mayor visibilidad y por ende mayores ingresos. Una
forma de lograr esta adaptación es tener un mayor control y capacidad
de cambio en sus procesos de negocios para generar más valor a sus
FOLHQWHV(VWRVLJQL¿FDTXHXQLGRDODH¿FLHQFLD\ODH¿FDFLDGHEHLUOD
capacidad del negocio para adaptarse al entorno cambiante, mediante
los ajustes en sus propios procesos. A este propósito fundamental
11

apunta BPM como disciplina integradora de las capas de negocio y la

capa tecnológica para la gestión empresarial por procesos.
Según Hitpass (2013, 11), un proceso de negocio es un conjunto de
actividades impulsadas por eventos y ejecutadas en una secuencia
HVSHFt¿FDTXHJHQHUDQYDORUSDUDHOFOLHQWH/RVSURFHVRVGHQHJRFLRV
son transversales a las áreas e involucran toda la cadena de valor.
Hay que tener en cuenta que gestión de procesos y gestión por procesos
son dos conceptos diferentes. El primero hace referencia a gestionar pro-
cesos particulares con el propósito de obtener mayor control y desem-
peño de estos, para mejorar el grado de cumplimiento de los objetivos
funcionales, sin considerar otras capas del negocio como la estrategia
o la tecnología. La gestión de procesos enfatiza en las acciones y en
las funciones de las personas, mientras que la gestión por procesos
plantea alinear la capa de operaciones con la estrategia del negocio
KDFLHQGRXVRH¿FD]GHODWHFQRORJtDGLVSRQLEOHHVGHFLUORVSURFHVRV
deben seguir la estrategia y la tecnología debe seguir a los procesos,
este es uno de los principios de BPM, señala Hitpass (2013, 14).
1.1 Business Process Management, BPM
El concepto de gestión de procesos de negocio (Business Process
Management, BPM) fue utilizado inicialmente por Smith & Fingar (2002,
UH¿ULpQGRORFRPRODWHUFHUDRODHQODLQJHQLHUtDGHSURFHVRV3DUD
Jeston & Nelis (2008, 9), es el logro de los objetivos empresariales a
través de la mejora, la gestión y el control de los procesos de negocio,
que abarca aspectos de análisis, modelado, implementación y ejecución
de los procesos.
Según Garimella, Lees & Williams (2008,5), hace referencia a un
conjunto de mejores prácticas de gestión de procesos, herramientas
y tecnologías utilizadas para analizar, diseñar, representar, y controlar
los procesos del negocio. Se enfoca a los procesos, combinando las
tecnologías de la información con metodologías de proceso y gobierno.
BPM integra el recurso humano del negocio y del área de tecnologías
GHLQIRUPDFLyQFRQHOSURSyVLWRGHGH¿QLUSURFHVRVUiSLGRVHIHFWLYRV
y transparentes de negocio a toda la organización.
«%30HVXQHQIRTXHVLVWHPiWLFRSDUDLGHQWL¿FDUOHYDQWDU
documentar, diseñar, ejecutar, medir y controlar tanto los
procesos manuales como automatizados, con el propósito
de obtener resultados consistentes para el logro de los
objetivos del negocio que están alineados con la estrategia
organizacional. BPM incluye el soporte integral de las tecno-
logías de información para mejorar, innovar y gestionar los
procesos que determinan los resultados del negocio, crean
12

valor para el cliente y facilitan el logro ágil de los objetivos

del negocio» (ABPMP, 2009, 12).
1.2 Herramientas para BPM
Como se mencionó anteriormente, el concepto de BPM es bastante
amplio y abarca diversos aspectos, por lo que no es viable pensar en
una herramienta universal que los cubra a todos. Sin embargo, en el
mercado existen diferentes herramientas, desarrolladas para apoyar
DOJ~QDVSHFWRHVSHFt¿FRGH%30+LWSDVVSODQWHDODVLJXLHQWH
FODVL¿FDFLyQ
- Herramientas para análisis y gobierno corporativo (BPM Gover-
nanceTXHLQFOX\HODSODQL¿FDFLyQDQiOLVLVJHVWLyQ\FRQWUROGH
la estrategia y el modelo del negocio. Estas son las plataformas
para análisis de procesos de negocios (Business Process Analysis,
BPA) y las herramientas de arquitectura empresarial (Enterprise
Architecture, EA).
- Herramientas para la automatización de procesos, conocidas como
sistemas para la gestión de procesos de negocios (Business Process
Management Suite, BPMS).
- Herramientas para la gestión de reglas de negocios independien-
temente de los sistemas que las utilizan, conocidas como Motores
de Reglas o BRMS (Business Rules Management System).
- Herramientas para implementar en tiempo real indicadores de control
de gestión (Business Activity Monitoring, BAM).
- Herramientas para orquestación de servicios entre BPMS y otros
sistemas, conocidas como SOA Suite.
- Herramientas para minería de procesos, es decir, para realizar aná-
lisis de datos históricos generados por los procesos con el propósito
GH LGHQWL¿FDU GHVYLDFLRQHV R GHVFXEULU SDWURQHV Process Mining
Tools).
1.3 Business Process Management y
Service Oriented Architecture
La Arquitectura Orientada a Servicios (Service Oriented Architecture,
SOA) es un marco de diseño para integrar aplicaciones independientes
y ofrecerlas como servicios, de tal forma que se pueda acceder a sus
funcionalidades desde diversos entornos. La orientación a servicios
permite interoperar con aplicaciones y actores externos como clientes
o proveedores, invocándolos mediante servicios reutilizables. SOA es
una iniciativa de integración que permite interconectar herramientas
de software, se basa fundamentalmente en la tecnología de los ser-
vicios web.
13

BPM y SOA son iniciativas independientes, pero tienen en común que

ambas se apoyan en tecnologías basadas en servicios. La combina-
ción de BPM y SOA se vislumbra como el enfoque más apropiado que
tiene una organización para alcanzar una alineación más precisa entre
los procesos de negocio y los recursos de TI, y así lograr la agilidad
requerida para el negocio y la capacidad de respuesta a los requeri-
mientos cambiantes en la organización y en el entorno, de acuerdo con
Kamoun (2007, 2).
Según Hitpass (2013, 40), el modelo estructural de BPM y SOA se puede
ver como una arquitectura integrada de la capa del negocio y la capa
tecnológica, compuesta por los siguientes elementos:
- La capa correspondiente al gobierno de procesos de negocio (Bu-
siness Process Governance %3* TXH GH¿QH OD HVWUDWHJLD SDUD
adaptar los productos y servicios de la empresa a las necesidades
del entorno.
- Una subcapa que incluye un componente de diseño y control que
WLHQHFRPRLQVXPRVODHVWUDWHJLDGH¿QLGDHQODFDSDGHJRELHUQR\
el análisis del comportamiento del negocio. Puede incluir procesos
de simulación.
- La capa de ejecución de procesos de negocio (Business Process
Execution, BPE) incluye la implementación tecnológica de los pro-
cesos diseñados. Su entrada es el modelo de procesos de negocio
que sea automatizable según la lógica del negocio. Incluye la suite
de gestión de procesos de negocio BPMS.
- La capa SOA que contiene los diferentes servicios ofrecidos a los
usuarios. Esta capa interactúa con el BPMS mediante un bus de
servicios (Enterprise Service Bus, ESB), que es un middleware
entre el motor de procesos y las aplicaciones, que permite invocar
y orquestar servicios y aplicaciones.
1.4 Business Process Management Suite, BPMS
BPMS es el software empresarial que soporta la gestión de procesos
de negocio, mediante la implementación de los principios teóricos de
BPM, que permite modelar, implementar y ejecutar procesos de nego-
cio en una organización, así como facilita la integración y gestión de
los procesos manuales y automáticos a lo largo de toda la cadena de
valor, a través de la orquestación de procesos, personas, aplicaciones
y la información corporativa.
De acuerdo con Tormo (2012), es un servidor de procesos para gestionar
integralmente los procesos de negocios, que incluye módulos funcio-
nales, capacidades técnicas y la infraestructura tecnológica necesaria.
14

Para Synergo (2012), es un conjunto de metodologías y soluciones tec-

QROyJLFDVSDUDHODQiOLVLVGH¿QLFLyQJHVWLyQDXWRPDWL]DFLyQ\FRQWURO
GHORVSURFHVRVGHQHJRFLRFRQHOSURSyVLWRGHPHMRUDUODH¿FLHQFLD
operacional de la organización.
AuraPortal (2013) y Hitpass (2013, 41), coinciden en considerar que
un BPMS de última generación, debe contener al menos las siguientes
funcionalidades:
- Un modelador (diagramador) de procesos de negocios, que permite
representar integralmente todos los aspectos relacionados con los
procesos.
- Motor de procesos para la ejecución, administración y control de
todos los procesos de negocio.
- Sistema de gestión para editar y ejecutar reglas de negocios (Bu-
siness Rules Management System, BRMS).
- Motores de orquestación para invocar y orquestar servicios y aplica-
ciones mediante un bus de servicios (Enterprise Service Bus, ESB).
- Diseñador de formularios, consulta e informes, los primeros se
utilizan para la interacción de los usuarios con el sistema, los otros
para efectuar análisis de los resultados de la ejecución de procesos
y generar información histórica.
- Herramientas para inteligencia de procesos, tales como he-
rramientas BAM (Business Activity Monitoring), BI (Business
Intelligence),Cuadro de Mandos, KPIs (Key Perfomance Indicators)
entre otras.
- Herramientas para integración de los modelos con otros sistemas
como ERP o sistemas legacy.
1.5 Business Process Model and Notation BPMN
%301 HV XQD KHUUDPLHQWD JUi¿FD HVWDQGDUL]DGD SDUD HO PRGHODGR
GH SURFHVRV GH QHJRFLR TXH XWLOL]D XQ IRUPDWR GH ÀXMR GH WUDEDMR
(ZRUNÀRZ), desarrollada inicialmente por la organización Business
Process Management Initiative, BPMI, y mantenida actualmente por
el Object Management Group, OMG, después de la fusión de las dos
organizaciones en 2005. La versión vigente es BPMN2.0 que apareció
en 2011 (OMG, 2011).
El principal objetivo de BPMN es proveer una notación estándar que
sea fácilmente legible y entendible por parte de todos los involucrados
e interesados del negocio (stakeholders). Entre ellos están los ana-
OLVWDVGHQHJRFLRTXLHQHVGH¿QHQORVSURFHVRVORVGHVDUUROODGRUHV
técnicos, que son los responsables de implementar los procesos y
los gerentes o administradores del negocio, cuya responsabilidad
15

es monitorear y gestionar los procesos. BPMN tiene el propósito de

servir como lenguaje común para cerrar la brecha de comunicación
que frecuentemente se presenta entre el diseño de los procesos de
negocio y su implementación, asegura OMG (2011).
1.5.1 Elementos de notación de BPMN. El modelamiento en BPMN
se realiza mediante diagramas sencillos con un conjunto muy pequeño
GHHOHPHQWRVJUi¿FRVTXHLQFOX\HQVtPERORVUHODFLRQHV\DWULEXWRV
Con esto se busca que los usuarios del negocio y los desarrolladores
WpFQLFRVHQWLHQGDQIiFLOPHQWHHOÀXMR\HOSURFHVR(QODYHUVLyQ%301
2.0, señalan OMG (2011) y Freund, Rucker & Hitpass (2011, 27), las
FDWHJRUtDVEiVLFDVGHHOHPHQWRVVRQREMHWRVGHÀXMRREMHWRVGHFR-
nexión, canales, artefactos y datos. A continuación se describen bre-
YHPHQWHFDGDXQDGHHOODV/D¿JXUDPXHVWUDORVHOHPHQWRVEiVLFRV
de notación utilizados.
Figura 1. Elementos Básicos de Notación BPMN (OMG, 2011)
2EMHWRV GH ÀXMRSon los elementos principales que se describen

en BPMN:
- Actividades. Describen el trabajo desarrollado dentro de un proceso
de negocio, pueden ser atómicas o compuestas, se utilizan para
modelar tareas y subprocesos y pueden ser iterativas.
- Eventos. Describen algo que sucede durante el desarrollo de un
SURFHVR\TXHDIHFWDVXÀXMRJHQHUDQXQGLVSDURRUHVXOWDGR/D
frontera determina el tipo de evento. Según el momento en que
ocurran, existen tres tipos básicos de eventos: inicial, intermedio
\¿QDO
16

- Compuertas (Gateways &RQWUROHV GH VHFXHQFLD GH ÀXMR GHQWUR

de un proceso, como un punto de convergencia o divergencia. De-
terminan si se bifurca o se combinan las rutas dependiendo de las
condiciones expresadas.
2EMHWRVGHFRQH[LyQ5HODFLRQDQORVREMHWRVGHÀXMR\VRQ
- Flujo de Secuencia. Enlaza dos elementos, permiten mostrar la
secuencia en que las actividades se llevarán a cabo. Pueden ser
ÀXMRVQRUPDOHVFRQGLFLRQDOHVRSRUGHIHFWR
- Flujo de Mensaje. Indica el envío de un mensaje entre dos elementos
XELFDGRVHQSLVFLQDVGLIHUHQWHV8QÀXMRGHPHQVDMHQRSXHGHVHUXWL-
lizado para conectar actividades o eventos dentro de la misma piscina.
- Asociación. Se utiliza para conectar artefactos o elementos de datos
DXQREMHWRGHÀXMR
&DQDOHVSwimlanes). Representan los responsables de las activida-
des en un proceso, por ejemplo organizaciones, roles, áreas funcionales
o sistemas. Estos son:
- 3LVFLQD,GHQWL¿FDFDGDXQRGHORVSULQFLSDOHVSDUWLFLSDQWHVHQXQ
proceso. Una piscina puede contener uno o más carriles. Puede
ser abierta (muestra los detalles internos), o cerrada (esconde los
detalles internos).
- Carril. Muestra un rol o área funcional dentro de una piscina, se utiliza
para organizar y categorizar las actividades de acuerdo a funciones
o roles de las personas o áreas involucradas en un proceso.
$UWHIDFWRV. Elementos de documentación para hacer más compren-
sibles los diagramas:
- Comentario. Se utiliza para incluir una nota o comentario para des-
FULELURGRFXPHQWDUDOJ~QDVSHFWRHVSHFt¿FRGHOGLDJUDPD
- Agrupación. Se usa para agrupar diferentes actividades pero no
DIHFWDDOÀXMRGHQWURGHXQGLDJUDPD
- Símbolos propiosTXHHYHQWXDOPHQWHGH¿QHHOXVXDULR
'DWRVRepresentan archivos de datos, objetos de datos o documentos
que son producidos y/o consultados por un proceso o actividad. Los
tipos de datos son: dato de entrada, dato de salida, dato de tipo objeto,
colección de objetos de datos, almacén y mensaje.
2. Metodología
El proyecto de investigación referido, tiene como objetivo construir un
proceso integrado de desarrollo de software con base en los estándares
17

establecidos por MDA, los principios promovidos por MDSD y apoyado

en los lineamientos de BPM. Está culminado en su primera etapa, cuyo
SURFHVRUHVXOWDQWHLQFOX\HXQPDUFRGHWDOODGRTXHGHVFULEHHOÀXMRGH
trabajo, la asociación de diagramas y artefactos a cada nivel y la carac-
WHUL]DFLyQGHFDGDGLDJUDPD(VWHSURFHVRVHSHU¿ODFRPRXQUHDOL]DFLyQ
concreta de la propuesta de MDA y MDSD (Chaparro & Gómez, 2013, 18).
El proyecto abarcó diversos tipos de actividades globales que se abor-
daron mediante un tipo de investigación diferente así:
- Investigación Exploratoria. Mediante este tipo de investigación, se
LGHQWL¿FDURQORVSULQFLSLRVIXQGDPHQWDOHVGH0'$0'6'%30
BPMN, XMI y UML2. Se recopiló información relevante de cada uno
de los temas para conformar un texto general explicativo, mapas
conceptuales y cuadros que permitieron entender cada tema y su
relación con los demás temas.
- Investigación Descriptiva. Con base en la investigación explora-
toria, se hizo una caracterización de MDA, MDSD, BPM, BPMN,
XMI y UML. Para cada uno de los temas se describieron sus ca-
racterísticas relevantes vistas desde la perspectiva de los autores
más destacados, además de las guías que proporciona el OMG.
/DVGHVFULSFLRQHVHVWiQDFRPSDxDGDVGHHOHPHQWRVJUi¿FRVTXH
ayudan a expresar mejor cada tema.
- Caso de Estudio. Para comprobar las hipótesis de trabajo, se utilizó
como caso de estudio el sistema Alquiler de Vehículos, el cual se
ajustó para este proyecto. Adicionalmente, se hicieron pruebas a
técnicas y métodos que se utilizaron para conformar proceso de
desarrollo de software. Para el modelado del caso se utilizó la he-
rramienta Business Process Model and Notation, BPMN. Al análisis
GHORVUHVXOWDGRVREWHQLGRVHQHVWHDVSHFWRHVSHFt¿FRVHHQIRFD
particularmente el presente artículo.
- Investigación y Desarrollo I+D. Mediante I+D se construirá el proceso
de desarrollo de software; esto implica su marco general, etapas,
PRGHORV\HVSHFL¿FDFLyQGHFRUUHVSRQGHQFLDVHQWUHPRGHORV
3. Resultados y discusión
Para ilustrar el proceso y la conformación de los niveles MDA se usó
como caso de estudio el sistema Alquiler de VehículosTXHVHPRGL¿Fy
\DPSOLySDUDHVWHSUR\HFWR(OFDVRVHUH¿HUHDXQDHPSUHVDTXHWLHQH
por actividad principal el servicio alquiler de diversos tipos de vehículos.
Las operaciones de compra de vehículos suelen considerar la venta de
los mismos al cabo de cierto período de tiempo. El sistema debe realizar
18

la gestión de compra, alquiler, mantenimiento y venta de vehículos, así

como la gestión de los tipos de clientes que operan con la empresa. Para
el modelado del caso de estudio se utilizó el lenguaje de notación BPMN.
Entre los resultados de la primera etapa del proyecto está la elaboración
del modelo independiente de plataforma CIM (por sus siglas en inglés), que
abarca la descripción del negocio, el modelo de proceso del negocio, el
vocabulario del negocio, las reglas de negocio y los requisitos funcionales.
3.1 Modelado de Procesos de Negocios
Teniendo como referencia el caso de estudio mencionado, en el nivel
de Modelo Independiente de Plataforma CIM, se elaboró el Modelo de
Procesos de NegocioHOFXDOGHVFULEHJUi¿FDPHQWHORVSURFHVRVSUR-
pios de la organización. Para elaborar los diagramas correspondientes
se utilizó la herramienta Enterprise Architect. El modelo de procesos
de negocio está conformado por un diagrama general que representa
el proceso global en términos de actividades básicas y subprocesos.
7DPELpQVHXWLOL]DQGLDJUDPDVHVSHFt¿FRVTXHGHWDOODQFDGDXQRGHORV
subprocesos del diagrama general. Para el caso de estudio Alquiler de
Vehículos, el proceso general está conformado por los subprocesos:
‘Elaboración de Contrato de Alquiler’, ‘0RGL¿FDFLyQDO&RQWUDWRGH$O-
quiler’ y ‘Devolución Vehículo y liquidación de contrato’.
/D ¿JXUD PXHVWUD HO GLDJUDPD JHQHUDO FRUUHVSRQGLHQWH PLHQWUDV
ODV)LJXUDV\SUHVHQWDQORVGLDJUDPDVHVSHFt¿FRVTXHLOXVWUDQORV
respectivos subprocesos.
Figura 2. Diagrama general proceso de alquiler de

vehículo (Chaparro & Gómez, 2013, 24)
19

)LJXUD'LDJUDPDHVSHFL¿FRGHOVXESURFHVR'HYROXFLyQGHO9HKtFXOR\
Liquidación deContrato de Alquiler (Chaparro & Gómez, 2013, 27)
)LJXUD'LDJUDPDHVSHFL¿FRGHOVXESURFHVR(ODERUDFLyQGH
Contrato de Alquiler (Chaparro & Gómez, 2013, 25)
3.2 Análisis de BPMN como estándar de

modelado de procesos de negocio
Para este análisis se tuvieron en cuenta en gran medida los plantea-
mientos de varios autores, entre ellos Silver (2011, 17) y White & Miers
(2009, 192), así como las lecciones aprendidas, la experiencia y los
20

resultados obtenidos con la aplicación de BPMN en el modelado del

caso de estudio alquiler de vehículos.
%301FRPR+HUUDPLHQWD*Ui¿FD
%301VHGH¿QHFRPRXQDKHUUDPLHQWDJUi¿FDHVWDQGDUL]DGDSDUDOD
notación del modelado de procesos de negocio, basado en un formato
GHÀXMRGHWUDEDMR
+HUUDPLHQWDZRUÀRZ. Para empezar se tiene que a pesar de
TXH%301VHEDVDHQHOFRQFHSWRGHÀXMRGHWUDEDMRSDUDGyMLFDPHQWH
VXSRWHQFLDOLGDGSURYLHQHGHOKHFKRTXHGL¿HUHVXVWDQFLDOPHQWHGHORV
GLDJUDPDV GH ÀXMR WUDGLFLRQDOHV /DV SULQFLSDOHV GLIHUHQFLDV VRQ ODV
siguientes:
- %301 HVWi EDVDGR HQ XQD HVSHFL¿FDFLyQ IRUPDO TXH LQFOX\H XQ
metamodelo y reglas de uso. Su expresividad se basa en una amplia
gama de marcadores, iconos y estilos que determinan la semántica
de cada forma básica. Posee reglas que gobiernan el uso de cada
elemento de notación y su relación con otros elementos.
- BPMN puede describir el comportamiento de un evento activado. Un
evento es algo que sucede mientras el proceso está en desarrollo.
Un modelo determina qué hacer cuando se presentan excepciones
en el desarrollo de un proceso.
- %301DGHPiVGHUHSUHVHQWDUHOÀXMRGHQWURGHXQSURFHVRGHVFUL-
be las comunicaciones entre los procesos y las entidades externas
como los usuarios, los proveedores externos de servicios y con
otros procesos internos.
3.3.2 Uso de notación básica.. BPMN provee los elementos de nota-
FLyQJUi¿FDODVUHJODVVLQWiFWLFDV\ODVUHJODVVHPiQWLFDVSDUDHODER-
rar Diagramas de Procesos de Negocio (Business Process Diagram,
BPD), que representan la secuencia de actividades que hacen parte
de un proceso. Estos diagramas son sencillos y comprensibles tanto
para el personal técnico como no técnico, involucrado en la gestión
de procesos de negocio. A pesar de su simplicidad, los BDP permiten
manejar adecuadamente la complejidad inherente a los procesos de
negocio. BPMN utiliza menos símbolos básicos, pero estos tienen más
YDULDFLRQHVTXHORKDFHJUi¿FDPHQWHPiVFRPSOHWR
3.3.3 Modelo semántico asociado. Un modelo BPMN consiste en una
UHSUHVHQWDFLyQJUi¿FD\HOPRGHORVHPiQWLFR;0/VXE\DFHQWH&DGD
HOHPHQWRJUi¿FRHQHOPRGHORFRUUHVSRQGHDXQHOHPHQWRVHPiQWLFR
(Q%301WDQWRHOPHWDPRGHORFRPRODVGH¿QLFLRQHVGHHOHPHQ-
tos y las reglas asociadas, hacen referencia a elementos semánticos,
QRDORVHOHPHQWRVJUi¿FRVGHOGLDJUDPD(VSRVLEOHWHQHUXQPRGHOR
21

VHPiQWLFR SURFHVR OyJLFR GH¿QLGR HQ ;0/ VLQ XQ PRGHOR JUi¿FR
relacionado (diagrama), pero no el caso contrario.
3.4 BPMN según sus características
estructurales y de integración
En la versión BPMN 2.0 lo más importante y en lo que se hace más
énfasis es en el modelado, más que en la notación. El modelo está
HQIRFDGRHQODVHPiQWLFDIRUPDOGHODVGH¿QLFLRQHVGHORVHOHPHQWRV
\VXVLQWHUUHODFLRQHVGH¿QLGDVHQHOPHWDPRGHORDVtFRPRVXUHSUH-
sentación en XML. BPMN 2.0 provee un formato de intercambio XML
para los modelos de proceso. El metamodelo permite ejecutar directa-
PHQWHORVPRGHORV%301HQXQPRWRUGHSURFHVRVHVWRVLJQL¿FDTXH
se pueden mapear explícitamente los modelos a un ambiente técnico,
por ejemplo Business Process Execution Language, BPEL, que es un
estándar para automatización de procesos basado en XML.
3.4.1 Niveles estructurales(Q%301VHSXHGHQLGHQWL¿FDUWUHVQLYHOHV
estructurales, así:
- El nivel uno, que corresponde a los elementos básicos de modelado
TXHVRQORVPiVXWLOL]DGRV\DTXHVRQVX¿FLHQWHVSDUDGHVFULELUOD
mayor parte del comportamiento del proceso.
- En el nivel dos se manejan las excepciones, haciendo énfasis en los
eventos relacionados con mensajes, tiempos, errores, condiciones
de negocio, señales y cancelaciones. Adicionalmente se incluye las
bifurcaciones y patrones de combinación.
- El nivel tres hace referencia al componente ejecutable, es decir, los
detalles XML que no se presentan en el diagrama, aspectos como
modelos de datos, expresiones condicionales y lógica de asignación
de tareas.
3.4.2 Niveles de abstracción6HLGHQWL¿FDQWUHVQLYHOHVDVt
- El nivel más general son los mapas de procesos que son diagramas
VLPSOHVTXHUHSUHVHQWDQHOÀXMRGHDFWLYLGDGHV
- El siguiente nivel son las descripciones de procesos que agregan
más detalles del proceso como roles de las personas y elementos
de datos involucrados.
- El último nivel son los modelos de procesos que son diagramas mu-
cho más detallados, que facilitan el análisis y simulación del proceso,
adicionalmente estos modelos se pueden ejecutar directamente en
un motor de procesos.
3.4.3 Nivel de representatividad. Según este criterio, BPMN soporta
el modelado de tres categorías de procesos, así:
22

- Orquestación. Muestra la perspectiva de ejecución coordinada de las

DFWLYLGDGHVTXHFRQIRUPDQXQSURFHVR'H¿QHORVSURFHVRVLQWHUQRV
SDUDXQSDUWLFLSDQWHHVSHFt¿FRRXQDRUJDQL]DFLyQ8QGLDJUDPD
BPMN puede incluir más de una orquestación, donde cada una
de ellas está contenida en una piscina, es decir, los elementos del
proceso coexisten en un entorno claramente establecido.
- &RUHRJUDItD 'H¿QH HQ IRUPD VHFXHQFLDO ODV LQWHUDFFLRQHV HQWUH
dos o más participantes, los cuales pueden ser roles o entidades.
Describe la comunicación entre piscinas mediante el intercambio
público de mensajes, en el ámbito de una colaboración. A diferencia
de la orquestación, la coreografía no necesariamente existe dentro
GHXQFRQWH[WRHVSHFt¿FR
- Colaboración. Hace referencia a un diagrama BPMN que contenga
dos o más participantes, puede incluir una coreografía y una o más
orquestaciones.
BPMN tiene un marco conceptual oculto, plasmado en la semántica de
ORVGLIHUHQWHVHOHPHQWRVGH¿QLGRVSRUHOHVWiQGDUWDOHVFRPRSURFHVR
actividad, evento, lógica del proceso y orquestación entre otros. Es in-
dispensable que la persona que ejerza el rol de modelador de procesos,
WHQJDODFODULGDGFRQFHSWXDOVX¿FLHQWHSDUDJDUDQWL]DUHOXVRFRUUHFWR
del estándar en el modelado de procesos de negocio.
8VRGHSDWURQHVGHZRUNÀRZ. BPMN puede representar más
patrones de ZRUNÀRZ, en comparación con otras notaciones existentes.
Teniendo en cuenta los patrones propuestos por Van Der Aalst et al.
(2002, 5), BPMN permite expresar los patrones básicos de control de
ÀXMRDVt
- Secuencia. Representa dependencia entre tareas, el orden de
ejecución de estas.
- División Paralela. Señala un punto del proceso donde un cami-
QR VH GLYLGH HQ GRV R PiV UDPL¿FDFLRQHV TXH VRQ HMHFXWDGDV
concurrentemente.
- Sincronización. Muestra un punto del proceso donde dos o más
UDPL¿FDFLRQHVVHXQHQHQXQDVRODVHHVSHUDTXHWRGDVODVUDPDV
se completen para continuar con la siguiente actividad.
- Decisión Exclusiva. Representa un punto del proceso donde se debe
seleccionar un único camino según una decisión.
- 8QLyQ6LPSOH'H¿QHXQSXQWRGHOSURFHVRGRQGHGRVRPiVFDPLQRV
alternos convergen en uno solo, estos caminos no son ejecutados
paralelamente.
23

Adicionalmente, permite representar los patrones avanzados de sin-

cronización y bifurcación, de múltiples instancias, basados en estados,
de cancelación y completamiento forzado, de interacción, de inicio y
de terminación.
6. Conclusiones
BPMN no es una metodología, proceso o marco de trabajo. Es una
KHUUDPLHQWDJUi¿FDHVWDQGDUL]DGDSDUDHOPRGHODGRGHSURFHVRVGH
QHJRFLRTXHXWLOL]DXQIRUPDWRGHÀXMRGHWUDEDMRZRUNÀRZ). No es
VX¿FLHQWHDSOLFDU%301SDUDLPSOHPHQWDU%30HQXQDRUJDQL]DFLyQ
se requiere tener en cuenta otras herramientas de análisis, gestión y
monitoreo de procesos de negocio.
$XQTXH%301VHVRSRUWDHQHOFRQFHSWRGHÀXMRGHWUDEDMRZRUNÀRZ),
HVPXFKRPiVTXHXQDKHUUDPLHQWDSDUDHODERUDUGLDJUDPDVGHÀXMR
de datos. Cada elemento básico de notación y los elementos deriva-
GRVWLHQHXQDVHPiQWLFDFODUDPHQWHGH¿QLGD%301HVWiEDVDGRHQ
XQDHVSHFL¿FDFLyQIRUPDOTXHLQFOX\HXQPHWDPRGHOR\UHJODVGHXVR
asociadas.
BPMN consolida las mejores prácticas en el modelado de procesos
de negocio aportadas por otros estándares que le precedieron. Fue
concebido como una herramienta genérica, es decir, es independiente
de cualquier metodología, herramienta de modelado o plataforma de
implementación. Se ha convertido en un estándar internacional, adop-
tado por las principales empresas que proveen productos BPM.
BPMN está enfocado particularmente al modelado formal de procesos
de negocio, por esta razón no incluye el modelado de otros aspectos
como estructuras organizacionales, estructuras de datos o infraestruc-
tura de TI. Es una herramienta sencilla que utiliza una notación estándar
que es fácil de comprender por parte de todos los involucrados en la
gestión de procesos de negocios. Esto permite disminuir la brecha de
comunicación entre el diseño de los procesos de negocio y su imple-
mentación práctica.
24

5HIHUHQFLDVELEOLRJUi¿FDV
ASSOCIATION OF BUSINESS PROCESS MANAGEMENT PROFESSSIONALS, ABPMP (2009).
Guide to the Business Process Management Body of Knowledge (BPM CBOK) [online]. Ver-
VLRQ¿UVWSXEOLFUHOHDVH&KLFDJR,/86$$%303S,6%1
<http://s.itb.ac.id/home/jayidoans@students.itb.ac.id/Magister%20Informatika%20ITB/IF5131-
ABPMP%20-%20CBOK-v2-0.pdf> [consult: 20/03/2014]
AURAPORTAL (2013). Business Process Management Suite[en línea]. Valencia (España): Aura
Portal.. <http://www.auraportal.com/PG534L1/AuraPortal--Advanced-Software-for-Enterprises-.
aspx> [consulta: 20/03/2014]
CHAPARRO, Luis Oliverio & GÓMEZ, Juan Federico (2013). Construcción de un Proceso de
Desarrollo de Software basado en Model Driven Architecture MDA, Model Driven Software
Development MDSD y Business Process Management BPM. Proyecto de Investigación, Grupo
Giprocas. Tunja (Colombia): Universidad de Boyacá, Programa de Ingeniería de Sistemas.
162 p.
FREUND, Jakob; RUCKER, Bernd & HITPASS, Bernhard (2011). BPMN 2.0: Manual de Refe-
rencia y Guía Práctica. 4 ed. Santiago de Chile (Chile): Camunda, BPM Center. 282 p. ISBN
978-956-345-182-5.
GARIMELLA, Kiran; LEES, Michael & WILLIAMS, Bruce (2008). Introducción a BPM para Dum-
mies. Edición Especial de Software AG. Indianapolis (USA): Wiley Publishing, Inc. 78 p. ISBN:
978-0-470-37359-0.
HITPASS, Bernhard (2013). Business Process Management (BPM): Fundamentos y Conceptos
de Implementación. 2 ed. Santiago de Chile (Chile): BPM Center - BHH Ltda. 308 p. ISBN:
978-956-345-977-7.
JESTON, John & NELIS, Johan (2008). Business Process Management. Practical Guidelines to
Successful Implementations.2 ed. Oxford (UK): Elsevier Ltd. 469 p. ISBN: 978-0-75-068656-3.
KAMOUN, Faouzi (2007). A Roadmap towards the Convergence of Business Process Management
and Service Oriented Architecture. In: ACM Ubiquity, Vol. 8, No. 14 (Apr.). New York (NY, USA):
ACM Publication. ISSN: 1530-2180
OBJECT MANAGEMENT GROUP, OMG (2011). Business Process Model ande Notation (BPMN);
Version 2.0 [online]. Needham (MA, USA): Object Management Group, Inc. 508 p. <http://
www.omg.org/spec/BPMN/2.0/PDF> [consult: 20/03/2014]
SILVER, Bruce. (2011). BPMN Method and Style: with BPMN Implementer’s Guide. 2 ed. Aptos
(CA, USA): Cody-Cassidy Press. 286 p. ISBN: 978-0982368114
SMITH, Howard & FINGAR, Peter (2002). Business Process Management: TheThird Wave. Tampa,
(FL, USA): Meghan Kiffer Press. 312 p. ISBN-13: 978-0929652344.
SYNERGO! (2012). BPMS y Negociática [en línea]. Llanes (Asturias, España): Sinergo! <http://
www.synergo.es/?p=2899> [consulta: 03/28/2013].
TORMO TRILLES, Suso (2012). El ROI que genera la utilización de un BPMS en cualquier tipo de
empresa [en línea]. Valencia (España): Aura Portal. <http://blog.auraportal.com/wp-content/
uploads/2012/01/Webinar-El-ROI-que-genera-el-BPMS-en-cualquier-tipo-de-empresa-ENE-
RO-2012.pdf> [consulta: 20/03/2014]
9$1 '(5$$/67 : +2)67('($ .,(386=(:6., % %$5526$ :RUNÀRZ
Patterns. Eindhoven (The Netherlands): Department of Technology Management, Eindhoven
University of Technology. 70 p.
WHITE, Sthepen A. & MIERS, Derek (2009). Guía de Referencia y Modelado BPMN. Lighthouse
Point, Florida (USA): Future Strategies Inc. 213 p. ISBN: 978-0-9819870-3-3.
25

clase 8
Actividad 1: Descubrir los Requisitos Duraderos y Volátiles
1- Los pedidos siempre son despachados por correo, nunca por medio de
comisionistas o empresas de bus. Tipo: D
Justif.: aparenta ser una política de la empresa, por lo tanto es algo cuyo
objetivo debe ser persistente en el tiempo.
2- El costo de los envíos es $180,00 a cualquier parte del país. Tipo: V
Justif.: dado un contexto inflacionario es poco probable que un costo se
mantenga estable en el tiempo. Por otro lado, también es difícil pensar
que el costo de envío físico de un producto sea igual a todo el país, dada
las grandes diferencias de distancia que producen diferentes costos. Por
lo tanto es un monto determinado de forma artificial.
3- Requerimos que se especifique la dirección de destino y los datos de la
persona que recibirá el paquete. Tipo: D
Justif.: la naturaleza misma de un pedido de delivery implica que se debe
determinar el domicilio a donde enviarlo y la persona que lo va a recibir.
4- El cliente puede, si lo desea, realizar el seguimiento del paquete por
medio de la web de la empresa. Tipo: V
Justif.: podría, dado que se envía por medio de un correo, realizar el
seguimiento por la página web del correo mismo, por lo que el servicio
requerido tiene un sustituto que lo iguala en calidad, esto implica un gasto
extra en la empresa que es posible que pueda ser recortado.
Actividad 2: Modelar un proceso en BPMN.
El modelo de BPMN a realizar es el siguiente:

Es importante tener en cuenta que los requisitos deben verificarse para determinar
clase 8 su exactitud y su completitud. Una de las formas de verificarlos es contrastarlos
conclusiones con un modelo del proceso de negocios para determinar su adecuación. Si no se
adecua, si no encaja en este modelo entonces se dispara una alerta dado que
pueden estar ocurriendo alguna de dos cosas:
- El requisito no es correcto (lo que implica que no se debe avanzar

con el mismo dado que no será luego utilizado o producirá resultados
erróneos)
- El modelo del negocio no es correcto (lo que implica que hay una
comprensión inadecuada del dominio del sistema)
Ahora, ¿todos los requisitos deben ser validados contra el proceso? No, lo
fundamental es validar aquellos que sean duraderos y no los volátiles.

clase 9 COMPILANDO LOS REQUISITOS EN UN DOCUMENTO PARA COMPARTIR
introducción
Lo que buscamos en esta clase es que adquiera conocimientos de formatos

de documentos de especificación de software y comprenda su utilidad.
Principalmente lo haremos conociendo la norma Std. IEEE 830 – 1998, que si
bien ha sido superada por una más reciente, es muy útil para introducirse en el
mundo de las SRS (o ERS si tomamos las siglas en español de Especificación de
Requerimientos de Software).
A la norma la conoceremos primero a través de sus partes, y luego comprenderemos

cada una de ellas con un ejemplo.
clase 9 Uniéndolo todo en un documento.

tema 1
Una vez que relevamos, y que hemos validado lo relevado podemos armar
lo que se denomina la SRS (especificación de requerimientos de software,
las siglas SRS están en inglés).
La SRS es lo que los desarrolladores deben

implementar. Debe incluir los requerimientos de los
usuarios y los requerimientos del sistema. Es habitual
que un requerimiento de usuario sea una introducción
y los requerimientos del sistema sean los detalles del
requerimiento del usuario.
Atención La SRS puede ser un documento único o puede
estar subdividido por algún criterio, como ser uno
documento por cada requerimiento, uno por cada
módulo, uno por cada usuario referente u otros más.
Esta división no afecta al contenido.
Puede incluso dividirse en requerimientos del usuario por un lado y requerimientos

del sistema por otro con sus correspondientes referencias para poder moverse
de uno al otro.
Pero, la pregunta es, ¿Por qué debemos compilar todo lo relevado en un

documento o una colección de ellos?

Al menos por dos razones que son las más valederas:
- Ordenar: nos permite mantener un orden de los requisitos de forma

tal de saber ubicar cada uno de ellos.
- Compartir: es necesario que los requisitos se compartan entre los
especialistas en informática y los interesados, el tenerlos “todos
juntos” y “ordenados” nos facilita la tarea.
- Aceptar: nos sirve como herramienta para verificar lo realizado, es
la base contra la cual se compara el software desarrolla para indicar
su aceptación o no.
Una tercera razón que no siempre aplica:

- Comprometer: cuando el desarrollador es ‘externo’ al usuario/cliente:
la SRS sirve a modo de ‘contrato’.
De todas maneras la Ingeniería de Software ha ido evolucionando con el tiempo,

y con la aparición de los métodos ágiles la SRS no desapareció pero si adoptó
otro formato:
- Los requisitos dejaron de formar parte de un documento monolítico
(o a veces modular) y pasaron a ser, si por ejemplo nos basamos en
SCRUM, un Backlog de ‘Historias de Usuarios’ escritas en tarjetas o
en aplicaciones que nos permiten simularlas.
Con los métodos ágiles, este documento llamado SRS desapareció. No es más
un documento, pero su contenido persiste, no puede dejar de existir. La razón
de este cambio es simple, se vive en un entorno dinámico, luego, los requisitos
pierden validez parcial o totalmente a lo largo del tiempo. Este tiempo se debe
comparar con el tiempo que insume el desarrollo del software, que usualmente
no es poco. Si son similares o el tiempo en que cambia en menor al tiempo de
desarrollo entonces, nuestro SRS perderá vigencia y el software realizado no
cumplirá con su objetivo. No podemos saber cuánto tiempo insumirá este cambio
de los requisitos, por lo que lo mejor es ser ágiles al momento de desarrollar el
software.
En resumen, sin importar si lo que realizamos es un documento único llamado

SRS o dejamos especificados los requisitos en pequeñas Historias de Usuarios
cambiantes los contenidos son los mismos.
Luego, ¿a quienes va dirigido este contenido? Los destinatarios son varios,

comencemos a ver el tema con el siguiente cuadro:

Basado de: “Ing. de Software, 9° Ed. – Sommerville, Ian. Pag. 92”
Como vemos el documento de requerimientos a apunta a personas dispares

dentro de la organización por lo que el mismo debe estar realizado en un lenguaje
que sea un compromiso entre todos.
Este documento debe contener los requisitos. Ahora la pregunta que nos debe
surgir es ¿Cómo lo organizamos al documento? Una posible respuesta es
basarnos en el estándar, ANSI – IEEE Std. 830-1998. No es necesario seguirlo
al pie de la letra, pero es una guía. Dicho de otra manera, no es necesario
seguir el formato (orden) propuesto por el estándar pero si deben, de una u otra
forma, existir dentro del documento todos los contenidos especificados por dicho
estándar.
El contenido y el orden que menciona el estándar es el siguiente:

1. Introducción
• Propósito.
▪ Alcance
• Definiciones acrónimos y abreviaturas
▪ Referencias
• Panorama
2. Descripción general
• Perspectiva del producto:(Interfaces del sistema, del usuario,
hardware, software, de comunicación, restricciones de memoria, operaciones,
requisitos de adaptación)
• Funciones del producto
▪ Características del usuario
• Restricciones
▪ Suposiciones y dependencias
• Distribución de requisitos
3. Requisitos específicos
• Interfaces Externas
• Funciones
• Requisitos de Rendimiento
• Restricciones de Diseño
• Atributos del Sistema
4. Información de apoyo
En el próximo tema ampliamos cada punto.

apartado que conforma la bibliografía básica:

Actividad 1: Armemos una pequeña especificación
Los ingenieros de Desarrollo (programadores) y los

Actividad
ingenieros de Prueba (testeadores) del sistema son dos de
los destinatarios de la SRS. Y para ellos es muy importante
dado que es la guía de su trabajo.
La consigna de esta actividad es pensar una pequeña
especificación, simple, y que describa detalladamente la
información para el desarrollo y la información para la
prueba.
La especificación debe ser sobre una pequeña
funcionalidad del sistema de facturación que consiste en
generar un documento que el cliente lleva hasta la caja para
realizar el pago de su compra. Este documento menciona
los datos del cliente (para que el cajero valide) y el monto a
pagar en efectivo. ¡Adelante!
Ampliando el Std. IEEE 830

clase 9
tema 2
En el Tema 1 de esta clase mencionamos el contenido que plantea este estándar,
entendamos ahora a que se refiere cada uno de ellos.
Introducción: este apartado “1. Introducción” es la introducción al documento
indicando en:
Propósito: cual es el objetivo y a quien va dirigido el documento.
Alcance del producto: se especifica que hará y que no hará el producto
a desarrollar
Definiciones: de los acrónimos y abreviaturas propios del dominio que se
utilizan a lo largo del documento.
Referencias: simplemente una lista de los documentos relacionados a la
SRS mencionados en la misma para ampliar o consultar información.
Panorama: describe brevemente el resto de los contenidos y la
organización de los mismos.
Descripción General: este apartado contiene aquellos factores que afectan al
producto y a sus requisitos pero no los requisitos en sí mismos (que se incluyen
en el próximo apartado), sino su contexto.
Perspectiva: debe relacionar al futuro producto con otros sistemas
existentes o futuros indicando el interface entre ellos. Si el desarrollo es parte de
un sistema mayor también debe especificarse la conexión.
Funciones del producto: debe describir grosso modo las funcionalidades
del producto (a muy alto nivel).
Características del usuario: debe describir las características de los
usuarios (perfil de los mismos mencionando aspectos relevantes al sistema, por
ejemplo: nivel educacional, experiencia técnica, uso de herramientas office…)

Restricciones: aquí se describen las limitaciones o imposiciones sobre el
trabajo a realizar, tanto para el producto mismo como para los desarrolladores y
el proceso de desarrollo en sí mismo.
Suposiciones y Dependencias: aquí de antemano indicamos
funcionalidades del sistema que sabemos que van a cambiar o pueden cambiar
si ocurren ciertos eventos en el negocio o en el contexto del sistema.
Requisitos Futuros: cambios en el sistema que se harán en futuras etapas
pero que pueden influir en el diseño actual.
Requisitos Específicos: este apartado es el núcleo, ¡aquí están los requisitos en

sí mismo! Aquí está todo lo que se relevó y verificó. Los requisitos de usuario y los
de sistemas. Los requisitos funcionales y los no funcionales. La norma no define
para este apartado una estructura, como en los dos puntos anteriores, consideran
que no es apropiado dada la gran variabilidad entre las organizaciones. Si debe
contener:
· Interfaces externas.
· Descripción de las funcionalidades.
· Requisitos de performance.
· Especificar la base de datos lógica.
· Restricciones de diseño.
· Atributos de calidad del sistema.
Aquí debe estar todo lo necesario para que los desarrolladores puedan diseñar
y desarrollar y para que los testadores pueden diseñar las pruebas y probar el
nuevo sistema y demostrar si satisface o no los requisitos
Lo que observamos aquí es que nuevamente nos quedamos sin respuesta

en la parte de cómo organizar los requisitos, más bien la descripción de las
funcionalidades. En las últimas versiones de la norma aparecen algunas formas:
· Por tipo de usuario
· Por objetos
· Por objetivos
· Por estímulos
· Por Jerarquía Funcional
Pero esta lista no es taxativa, nuevamente cada organización puede tener su

propio criterio.
Información de Apoyo – Apéndices: en este apartado simplemente incluimos

otra información relevante o relacionada con los requisitos pero que no sean los
requisitos en si mismos (ni forma parte de ellos).
Para comprenderlo mejor, veamos un ejemplo simple:

Como mencionamos en el tema 1 de esta clase esta no es la única forma de
crear una SRS, existen muchas. En la bibliografía básica, en el apartado que
proponemos para ampliar estos conocimientos se detalla otro formato:

Las restricciones que el usuario nos solicita en los relevamientos muchas veces
son expresiones de deseo y no restricciones reales. Muchas veces el usuario
nos solicita las restricciones y a su vez nos solicita la posibilidad de que existan
excepciones. Excepciones que terminan siendo la regla. Por lo tanto hay que
tener cuidado con esto dado que es muy posible que se gasten recursos escasos
de desarrollo para sumar una restricción a un sistema que simplemente luego
será pasado por alto el 100% de las veces. La forma práctica de distinguirlas
es si lo que nos platean como una restricción en realidad es una validación del
proceso de negocios o una política, o un uso y costumbre, estas restricciones
probablemente no sean restricciones sino simplemente validaciones o controles
que deben sumarse al sistema (y por lo tanto se ubican en distintos apartados de
la SRS).

Actividad 2: Restricciones
El objetivo de esta actividad es distinguir las restricciones

Actividad
de las validaciones en función de las excepciones a las
mismas
A continuación se enumeran una serie de restricciones

que pueden aparecer dentro de una SRS sobre las cuales
deberá reflexionar e indicar si son restricciones “firmes”
(no pueden tener una excepción durante la operación del
sistema) o “excepcionables”, o mejor dicho, las firmes son
realmente restricciones y las excepcionables son controles/
validaciones o reglas de negocio.
a. “el operador de las tarjetas, quien concentra las operaciones

electrónicas, PRISMA S.A. impone la utilización de su protocolo para la realización
de las transacciones”.
Restricción [ ] Control [ ]
b. “no se deben tomar pagos con más de una tarjeta de crédito. El monto
total de la compra debe saldarse con una sola tarjeta, pero el sistema debe estar
preparado para tomar pagos parciales con tarjetas”.
c. “la capacidad máxima de usuarios que pueden estar pagando con

tarjeta de crédito de manera concurrente es de 50, que es la cantidad de POSNET
virtuales que contratamos”.
d. “si el monto a pagar con tarjeta de crédito supera los $50.000,00 se

debe obtener el OK de un supervisor de facturación para poder operar, de lo
contrario no se puede cobrar con tarjeta de crédito más de ese monto”.

clase 9
claves de corrección Actividad 1: Armemos una pequeña especificación
Información detallada para el desarrollo: el sistema debe imprimir una hoja A4
en calidad borrador en la impresora única para todo el salón de ventas. Esta
hoja A4 llevará el titulo de “Comanda de Pago”. Luego deberá mostrar: apellido
y nombre del cliente, DNI, fecha de generación del documento, nro. de la caja
asignada, monto a pagar, concepto a pagar (descripción breve de la compra),
formas o formas de pago elegidas por el cliente y monto a abonar con cada una
de ellas, nombre y ID del vendedor, sección de la tienda donde se realizó la
compra, leyenda inferior ‘documento no fiscal’”.
Información detallada para la prueba: se espera que el sistema sea capaz de

manejar una cola de 100 documentos concurrentes. Se espera que el sistema
sea capaz de reimprimir el documento siempre y cuando no se haya abonado
ya en la caja. Se espera que los datos del documento sean coherentes con la
factura de compra emitida en la caja después de realizar el pago.
Actividad 2: Restricciones
a. “el operador de las tarjetas, quien concentra las operaciones

electrónicas, PRISMA S.A. impone la utilización de su protocolo para la
realización de las transacciones”.
Restricción [ X ] Control [ ]
Porque se contrato los servicios de dicho operador y a estos servicios

se accede por medio de ese protocolo. No se puede acceder al servicio por
medio de otro protocolo. Luego es una restricción real.
b. “no se deben tomar pagos con más de una tarjeta de crédito. El

monto total de la compra debe saldarse con una sola tarjeta, pero el sistema
debe estar preparado para tomar pagos parciales con tarjetas”.
Restricción [ ] Control [ X ]
Esto es un control del sistema que por la forma de pago solicitado

puede ser exceptuado, no es una restricción del desarrollo.
c. “la capacidad máxima de usuarios que pueden estar pagando con

tarjeta de crédito de manera concurrente es de 50, que es la cantidad de
POSNET virtuales que contratamos”.
Restricción [ X ] Control [ ]

Esto si es una restricción del sistema dado que lo contratado al
proveedor son 50 terminales concurrentes y no pueden ser superadas.
d. “si el monto a pagar con tarjeta de crédito supera los $50.000,00 se

debe obtener el OK de un supervisor de facturación para poder operar, de lo
contrario no se puede cobrar con tarjeta de crédito más de ese monto”.
Restricción [ ] Control [ X ]
Esto es un control, y puede ser exceptuado, con un ok de una persona

por lo tanto no es una restricción.
clase 9
conclusiones
Es importante tener en cuenta que el armado de una SRS (o ERS) es una tarea
fundamental del ciclo de vida de desarrollo del software, ya que que es la guía y
medida para evaluar el trabajo posterior. Debemos recordad que este documento
puede existir como un documento único, un conjunto o como historias de usuarios
en un backlog de temas a tratar (si usamos una metodología ágil) pero SIEMPRE
DEBE EXISTIR, de una u otra manera.

clase 10
introducción LA ESPECIFICACION FORMAL DEL SOFTWARE – USANDO LA
MATEMATICA DISCRETA PARA ELIMINAR LA AMBIGÜEDAD
En esta clase vamos a adentrarnos en las especificaciones formales de software,

que son parte de los métodos formales de desarrollo, su objetivo principal es
eliminar la ambigüedad de las especificaciones con el fin de asegurar los
resultados. Cuando desarrollamos una especificación de software, una SRS,
compilamos los requerimientos, obtenidos y validados por diversos métodos,
que nacen principalmente de la comunicación entre los individuos y terminan
expresándose en lenguaje natural con algunos aditamentos como tablas y
gráficos. Desde principios de los años 80 se está tratando de desarrollar lo que
se denomina los métodos formales que implican la utilización de 3 ramas de las
matemáticas discretas con el fin de eliminar la ambigüedad: la lógica, el cálculo
de predicados, la teoría de conjuntos. En esta clase nos introduciremos apenas
unos pasos en el mundo de uno de estos métodos: las especificaciones con la
notación Z.
clase 10
tema 1 Las Especificaciones Formales de Software
Hoy en día existe una disciplina denominada Ingeniería de Software. Pero,

al contrario de las restantes ingenierías, no hace uso habitual de las
matemáticas como parte del diseño del software ni tampoco para validar
este diseño mismo.
Por ejemplo, la ingeniería aeronáutica utiliza fórmulas matemáticas para simular

el desempeño de la estructura de una hélice de avión y conocer los límites a los
cuales puede llegar a operar.
Esto no es habitual en el software. En los años 80 comenzó

un movimiento que tenía este objetivo. Introducir las
matemáticas en el proceso de desarrollo de software.
Hoy en día aún no tiene un uso amplio y aceptado. Estos
métodos de desarrollo se denominan “Métodos Formales”
Atención
por la formalidad que les aporta un lenguaje como las
matemáticas, un lenguaje con una sintaxis, semántica y
vocabulario bien definido. En matemáticas siempre 2 + 2 = 4.

¿Y cuál era el objetivo? Eliminar principalmente la ambigüedad, como
vimos hasta ahora la principal técnica de relevamiento se basa el dialogo y
observación como herramienta, el dialogo se lleva a cabo en lenguaje natural
y lo que se observa se describe luego en lenguaje natural. Pero el lenguaje
natural es ambiguo, la conversación entre las personas es ambigua, y le damos
exactitud ampliándolo, “sacándonos” dudas. En lenguaje de las matemáticas no
existen las ambigüedades, como antes mencioné 2 + 2 siempre es 4.
Los Métodos Formales se basan en las matemáticas discretas: lógica de

predicados o de primer orden, teoría de conjuntos y algebra.
Los Métodos Formales utilizan estas 3 disciplinas como base misma de los
métodos, crear una “Especificación Formal”.
Una especificación formal es una “representación matemática” del software

(bueno, primero de sus requisitos). Luego los métodos formales incluyen
el análisis y prueba de esta especificación, el desarrollo transformacional, y la
verificación formal del software.
Existen varias razones por la que los métodos formales no han ganado espacio
en el mundo del desarrollo de software, y cuatro son las principales:
- La Ingeniería de Software, finalmente ha sido exitosa, al menos

comparado con los métodos de desarrollo anteriores.
- Los Métodos Formales no son escalables.
- Los Métodos Formales requieren conocimientos un poco más allá
de los tradicionales de un ingeniero de software y requieren que los
interesados también los tengan, los que no es usual.
- Alcance limitado en cuanto al software que podemos desarrollar, las
interfaces gráficas simplemente quedan fuera y hoy en día son un
componente fundamental que han dado nacimiento de estándares
(como ‘material design’ de google) o de disciplinas como la User
Experience – UX.
Estas y otras razones hacen que solo ciertos softwares sean susceptibles de ser
desarrollados por medio de los métodos formales, principalmente los softwares
críticos, donde tenemos que tener una elevadísima garantía de un correcto
desarrollo y funcionamiento, porque se ponen en juego costosísimos, o muy
escasos, recursos o vidas humanas: el soft de manejo de una central nuclear, o
el controlador de un avión o de la central que comanda un auto.
De todas maneras, las especificaciones formales, la base de los métodos formales,

son muy útiles y es lo que vamos a revisar ahora que hemos comprendido que
son estos métodos.

Las Especificaciones Formales tienen dos aproximaciones posibles:
- Las basadas en álgebra

- Las basadas en modelos
Las basadas en modelos definen el comportamiento de los sistemas indicando

como cada operación posible afecta el estado del sistema modelado. Especificando
todas las operaciones posibles nos modela el comportamiento del sistema entero.
Existen notaciones (lenguajes) que permiten crear estos modelos de

comportamiento. Uno de ellos es Z (Zed) creado por Hayes en 1987. En Z los
sistemas son modelados usando conjuntos y relaciones entre los conjuntos.
Para ampliar el contenido de este tema sugiero leer el

siguiente apartado del libro que conforma la bibliografía
Leer básica:
Sommerville, Ian. Ingeniería de Software 9° Edición. Pearson
Educación. México. 2011. - Webchunk capítulo 27 – Formal
Specifications.
Las transacciones en Z se modelan de manera mixta, ni 100% gráfico ni 100%

textual. Se utilizan los que se denominan ‘esquemas’.
Los esquemas se utilizan para incorporar variables de estado del sistema y las
restricciones y operaciones sobre ellas. Ciertos esquemas de Z pueden definir
operaciones del sistema (funcionalidades o partes de las mismas) se definen por
medio de pre y post condiciones, la diferencia entre ambas es la definición de la
operación en si misma (esto no es algo simple de comprender).
Para introducirse en el mundo de Z sugiero leer:

Cristia, Maximiliano – “Introducción a la notación Z” –
Universidad Nacional de Rosario (2015). http://www.fceia.
Leer unr.edu.ar/asist/z-a.pdf
Para ampliar el conocimiento de Z sugiero leer:

Woodcock & Davies – “Using Z” – University of Oxford. http://
www.usingz.com

Una especificación en Z define al menos dos esquemas: uno con la descripción
del estado del sistema y otra con las operaciones sobre ese estado.
Supongamos una lista de socios de un club, por cada socio almacenamos nombre
y DNI, definimos su estado y la operación de alta de socios:
[NOMBRES, DNIS]
Libro de Socios
nombre : ℙ NOMBRES
id : NOMBRES ⇸ DNIS
nombre = dom id
Alta Socio
ΔLibro de Socios
nuevo_nombre? : NOMBRES
nuevo_dni? : DNIS
nuevo_nombre? ∉ nombre
id′ = id ∪ {nuevo_nombre ↦ nuevo_dni}
nombre′ = nombre ∪ { nuevo_nombre }
¿Cómo interpretamos esta especificación? En el próximo tema de esta clase lo

vemos.

Actividad 1: Detectando la ambigüedad
La ambigüedad de la información o la falta de la misma,
deja huecos en la comprensión de lo relevado. Estos
Actividad
huecos tendemos a llenarlos de manera inconsciente con
nuestros conocimientos previos o con nuestra subjetividad.
Esto puede llevar a especificaciones erróneas, y luego a un
software erróneo. Lo que les propongo en esta actividad es
descubrir por qué un relevamiento es ambiguo:
“supongamos que el analista que está realizando el relevamiento ha trabajado

previamente en el desarrollo de un sistema de facturación, pero ahora tienen
que trabajar en el desarrollo de un sistema de facturación donde aparece una
novedad, al facturar, podemos introducir en la factura un concepto de descuento
que es el canje de millas por pesos de descuento.
Algo así: el cliente acumula millas con sus compras, al acumular 10.000 millas
puede canjearlas por $500 de descuento para su próxima compra”.
Recordemos diferenciar los dos momentos: la facturación de una venta y la

cobranza de esa factura.
Aquí la ambigüedad está en la última frase, más precisamente en las últimas

palabras “puede canjearlas por $500 de descuento para su próxima compra”.
¿Por qué? (ayuda, piense en los dos momentos antes mencionados) Si es

posible haga un ejemplo para cada uno con números inventados.
clase 10 El lenguaje Z – Interpretando una especificación formal

tema 2
La especificación de ejemplo que vimos en el tema anterior de esta clase era:
[NOMBRES, DNIS]
Libro de Socios
nombre : ℙ NOMBRES
id : NOMBRES ⇸ DNIS
nombre = dom id

Alta Socio
ΔLibro de Socios
nuevo_dni? : DNIS
id′ = id ∪ {nuevo_nombre ↦ nuevo_dni}
nombre′ = nombre ∪ { nuevo_nombre }
Ahora debemos interpretarla. Declaramos dos tipo de datos (dos conjuntos

según la teoría de conjuntos, uno contiene todos los nombres posibles y otro
todos los DNI posibles)
[NOMBRES, DNIS]
… entonces NOMBRES = {Pablo, Laura, Santiago, Azucena, Pedro,

Maria, Alberto, …} (todos los nombres posibles)
… entonces DNIS = {00000000, …, 99999999} (todos los dni posibles)
Declaramos un esquema que representa el estado del sistema:
Libro de Socios
nombre: ℙ NOMBRES
id: NOMBRES ⇸ DNIS
nombre = dom id
- ‘nombre’ es un conjunto del tipo NOMBRES, digamos puede contener

cero, uno o muchos nombres de los existentes en el conjunto
NOMBRES. Inicialmente nombre es igual al conjunto vacío (nombre
= ∅).
- ‘id’ es una función, que relaciona un ítem del conjunto NOMBRES con
un ítem del conjunto DNIS. Al ser una función la podemos representar
como una relación entre ítems del dominio y de la imagen

dominio imagen
. pablo . 28234572
. pedro . 35692456
. azucena . 59224156
- finalmente agregamos una restricción que indica que el conjunto

nombre debe ser igual al dominio de la función id. Esta restricción
debe ser siempre verdadera.
Luego, cuando especificamos como es el alta:
Alta Socio
ΔLibro de Socios
nuevo_dni? : DNIS
id′ = id ∪ {nuevo_nombre? ↦ nuevo_dni? }
nombre′ = nombre ∪ { nuevo_nombre? }
- Indicamos que la operación cambia el “estado del sistema”

anteponiendo el símbolo “Δ” al nombre del estado.
- Declaramos que la operación recibe dos datos, nuevo_nombre y
nuevo_dni, para indicar que son datos recibidos se les anexa al final
el símbolo “?”.
- Declaramos el tipo de estos datos que recibe el esquema, a nuevo_
nombre lo declaramos del tipo NOMBRES.
Luego, la 2° parte del esquema, desde la línea divisoria hacia abajo,

colocamos predicados que son las pre y poscondiciones que describen
como debe ser el estado del sistema antes y después de la operación y
estas pre y poscondiciones deben ser siempre ciertas.
La primera es una precondición, nuevo_nombre? ∉ nombre que nos

dice que el nombre que pretendemos agregar no debe existir previamente
en el conjunto nombre, digamos, nos describen el estado del sistema
antes que se ejecute la operación.

Las otras dos son poscondiciones que nos describen el estado del
sistema a posterior de la ejecución de la operación. Por supuesto deben
ser ciertas siempre (por cierta me refiero a que deben ser evaluadas a
TRUE o verdadero para el valor que asumen los datos).
id’ = id ∪ { nuevo_nombre? ↦ nuevo_dni? }
Lo que describimos aquí es que la función id a posterior de la operación

(por eso el apóstofre) es igual a la función id antes de la operación pero
con una nueva tupla, la formada por los datos de entrada, dado que una
función se puede representar, como dijimos antes, como una relación
entre ítems de dos conjuntos.
Por otro lado, también necesitamos actualizar el conjunto “nombre”
nombre′ = nombre ∪ { nuevo_nombre? }

Aquí nuevamente aparece el apostrofe indicando el valor de la variable
del estado a posterior de la operación, que en este caso nos dice que el
conjunto nombre es igual a nombre como estaba antes de la operación
unido a un conjunto que contiene solo el nuevo nombre.
Actividad 2: Especificando en Z
Actividad Lea los materiales complementarios, al menos el de
Maximiliano Cristia – “Introducción a la notación Z” y realice
el esquema de la operación de baja de un socio. ¡Adelante!
clase 10
Actividad 1: Detectando la ambigüedad
La frase es ambigua precisamente porque no aclara en cuál de los dos momentos
se aplica el descuento, y puede ser interpretado por quien es relevado en uno
de ellos, por quien releva en otro, por quien diseña, quien programa y testea en
cualquiera de los dos anteriores.
Veamos un ejemplo con nros, vendemos un parlante bluetooth de 100w, precio

$8000. El cliente por sus compras anteriores acumuló puntos y los cambio por un
descuento de $1000.
El descuento es un concepto de factura. El descuento se utiliza para cubrir

el pago.

Factura: Factura:
Parlante $8000 Parlante $8000
Descuento - $1000 *****
***** Total $8000
Total $7000
Abona en efvo en la caja: $7000 Abona en efvo en la caja: $8000

- $1000
*******
$ 7000
En ambos casos abonó lo mismo, pero facturo distinto, una factura se hizo por
$7000 y la otra por $8000, lo que implica que para el comercio que vende el IVA
que traslada al cliente es distinto. En la primera factura le trasladamos al cliente
$1214, 87 de IVA y en la segunda $1388,42. (Sería: $7000/1,21 = 1214,87 y
$8000/1,21 = 1388, 42).
Para el cliente es indistinto, pero para la empresa no. Cuando el desarrollo sea
revisado por la gente de contabilidad y detecte la diferencia del IVA aparecerá un
pedido de cambió sobre lo realizado.
(Este ejemplo no es estrictamente correcto, pero sirve para que veamos que la
ambigüedad existe y no es fácil detectarla).
Actividad 2: Especificando en Z
A continuación muestro una de las posibles formas de especificar en Z la baja de
un socio:
Baja de Socio
ΔLibro de Socios
dni_borrar? : DNIS
dni_borrar? ∈ nombre
id′ = {dni_borrar?} ⩤ id
nombre′ = nombre ∖ {id(dni_borrar?)}

clase 10
conclusiones Lo que hemos visto en esta clase es que la ambigüedad y la falta de información
existen en los relevamientos (y luego se reflejan en las especificaciones) y que
para eliminarla existen los Métodos Formales de Desarrollo, más precisamente
una parte de estos que son las Especificaciones Formales. Las Especificaciones
Formales nos ayudan a disminuir la ambigüedad del lenguaje natural mediante el
uso de un lenguaje no ambiguo: las matemáticas.
Ahora, evidenciamos que los métodos formales de especificación no son fáciles
de usar, requieren ciertos conocimientos, y no son aplicables al 100% de los
desarrollos, sino solo a algunas de sus partes.

clase 11
introducción
EL COMPORTAMIENTO INDIVIDUAL Y SU INFLUENCIA EN LAS
ORGANIZACIONES
En esta clase vamos a adentrarnos en el proceso de requerimientos. Primero

veremos los 4 grandes pasos, luego entraremos en detalles. Descubriremos dos
pasos más necesarios para la gestión de los requerimientos, uno de los cuales
deriva de una problemática de comunicación.
clase 11 Los pasos del Proceso de Requerimientos

tema 1
Al menos son cuatro los grandes pasos de un proceso de requerimientos, por
supuesto pueden variar según la organización, estas actividades de alto nivel
son:
1- Estudio de Factibilidad
2- Relevar y Analizar requisitos
3- Validar los requisitos
4- Especificar los requisitos
Estas actividades no son secuenciales, sino que forman parte de un proceso

iterativo donde interactúan los analistas o ingenieros encargados de los
requerimientos, los usuarios (y otros interesados) y los desarrolladores. Estos
pasos pueden incluso superponerse.

Más aun utilizando un proceso de desarrollo ágil. Lo importante es asegurarnos
que estos pasos NO DEBEN FALTAR. Siempre debemos llevar adelante un
estudio de factibilidad, siempre debemos relevar y analizar los requisitos de los
usuarios, luego validarlos y dejarlos asentados (“especificarlos”) para consulta.
¿Porque razones puede ocurrir esto? El análisis de los requisitos no debe ser una
etapa del proceso única en el tiempo que comienza y acaba previa al desarrollo,
es una actividad continua, recordemos, los sistemas no son estáticos dado que
los procesos que soportan no son estáticos en el tiempo, cambian.
Veamos cada uno de estos pasos, son simples, salvo el “Estudio de Factibilidad”
los restantes los hemos venido estudiando a lo largo de esta materia:
Estudio de Factibilidad:
Factible significa que puede ser hecho dentro de ciertas condiciones.

El estudio de factibilidad tiene como objetivo determinar
si el sistema puede ser implementado con la tecnología
seleccionada y en el tiempo y presupuesto dado (las
condiciones). Para ser realizado se necesitan los
Atención requerimientos, al menos preliminares, una descripción
simple del sistema esperado y objetivos a cumplir.
Durante el estudio de factibilidad se evalúa entre otros puntos:
- Cuáles son los problemas que tiene hoy el proceso a soportar y como
el nuevo sistema los va a solucionar.
- Como se obtendrá la información necesaria que el sistema necesita
para comenzar a funcionar (probablemente de un sistema anterior).
- Como se va a comunicar con otros sistemas de la organización (por
ejemplo, con el sistema contable).
- Si la tecnología elegida es la correcta para el desarrollo solicitado.
El resultado del estudio de factibilidad puede ser un simple “SI” o un simple “NO”
pero también puede ir más allá haciendo recomendaciones en cada uno de los
puntos considerados.
Relevar y Analizar los Requisitos:
Es trabajar en conjunto con los interesados para descubrir y analizar los

requerimientos. Llegar a una comprensión común de lo que se debe realizar, que
todos veamos lo mismo.
Validar Requisitos:
El objetivo es asegurarnos que hemos comprendido correctamente los requisitos,

es una buena práctica validarlos en el momento previo al comienzo del desarrollo.
Asegurarnos que todos veamos lo mismo.
Especificar:
Dejar asentados los requisitos, sea en un documento en papel o electrónico o en

otro formato. Pero siempre debemos tratar de hacerlo con un método o notación
que sea comprensible para todos los interesados.
El proceso descripto tiene 4 pasos y sería muy bueno agregar uno más:

Comunicación a Desarrollo
Bien, en el proceso con 4 pasos anteriores, nos basamos en una suposición:

dentro del equipo de desarrollo no se dan los problemas de comunicación que se
dan entre los analistas que llevan adelante el relevamiento y los usuarios. Pero
es muy probable que si se den.
Dependiendo como esté formado el equipo de desarrollo puede darse:
- Quienes relevan son los mismos que codifican

- Quienes relevan son un equipo de gente distinto a quienes desarrollan
Lo más habitual es la segunda alternativa, luego, una de las grandes ganancias

del proceso de relevamiento: que quienes relevan acuerden en un lenguaje
común una visión común con los interesados se pierde al transmitirse desde
quienes relevan a quienes desarrollan.
Lo mismo ocurre luego en la etapa de pruebas.
Entonces, lo mejor es involucrar a desarrolladores y a

testadores del sistema en el relevamiento mismo. Y
aun mejor, abrir un canal de comunicación entre los
desarrolladores y los interesados mismos, pero este canal
Atención debe estar bajo supervisión de algún líder que evalué los
cambios que surgen en estas comunicaciones y proceda
con la gestión del mismo.
La siguiente pata que le falta al proceso de Gestión de Requerimientos es la

administración de los mismos. Aspecto que vamos a revisar en el próximo tema
de la clase.
Para ampliar el contenido de este capítulo lea el siguiente

Leer Sommerville, Ian. Ingeniería de Software 9° Edición. Pearson
Educación. México. 2011. - Capítulo 4. Apartado 4.4. Y el
complemento web:
https://ifs.host.cs.st-andrews.ac.uk/Books/SE9/Web/
Requirements/FeasibilityStudy.html

clase 11 La Gestión de los Requerimientos
tema 2
La “Gestión de los Requerimientos” está enfocada a la gestión de los cambios de
los mismos.
Todo cambia, el entorno en el cual se debe desempeñarse el sistema cambia, los

usuarios cambian, los interesados cambian sus intereses, la empresa cambia sus
procesos y objetivos, el hardware en el cual estaba basado el sistema cambia, los
usuarios mismos a medida que van ganando experiencia cambian sus requisitos,
el equipo de desarrollo a medida que va ganado experiencia y conocimiento del
sistema también solicita cambios.
Luego, debemos gestionar estos cambios, por gestionar entendemos: descubrir,

comprender y controlar los cambios a realizar en el sistema.
Descubrir: lo usual es que los cambios lleguen al equipo de desarrollo como

pedidos desde los interesados o desde el equipo mismo. Pero no siempre es así,
muchas veces el mismo equipo de desarrollo debe estar atentos a los cambios en
la organización para poder adaptar el sistema. A partir de las metodologías ágiles
aparece un rol llamado Product Owner, este rol es el encargado de recabar y
descubrir los cambios en los requerimientos, priorizarlos y comunicarlos al equipo
de desarrollo. Aquí lo mejor es la apertura de canales de comunicación con los
interesados.
Comprender: quizás aquí lo más conveniente sea relevar, analizar y validar los
cambios, dado que esto nos va a llevar a la comprensión de los mismos, tal cual
se lleva cabo este proceso para los requerimientos originales.
Controlar: esta es la parte más jugosa, es la gestión en si misma de los

requerimientos y sus cambios. Primero, debemos clasificar los requerimientos,
como vimos en una clase anterior en Duraderos y Volátiles. Los duraderos exigirán
poca gestión de cambio, los otros, mucha. Luego, debemos tener un proceso
para recibir los pedidos de cambios, sean pedidos o descubrimientos, debemos
poder priorizarlos, luego analizarlos y determinar su impacto (tiempo, recursos,
costos), luego debemos desarrollar esos cambios y finalmente implementarlos.
El control debe comenzar cuando ya existen versiones preliminares de los
requerimientos.
El control de los requerimientos debe establecer un proceso formal que indique
como se van a gestionar los mismos.
Al tener un procedimiento formal vamos a conseguir que todos los cambios sean
tratados de la misma manera y evaluados de la misma manera.
Esta gestión de los cambios en los requerimientos entonces comienza con

la identificación de un problema en los requerimientos o con una propuesta
específica de cambio a los mismos.
Este problema o la propuesta de cambio se valoran para calcular su costo de

rehacer el relevamiento, especificación, desarrollo, prueba e implementación.
Esta valoración luego es evaluada y se decide si se continúa adelante con el

cambio o no.
Durante todo este proceso el requisito fue pasando por su propio ciclo de vida,
este ciclo de pida puede ser, básicamente el siguiente:

Adaptación de http://www.ie.inf.uc3m.es/grupo/docencia/reglada/Is1y2/Is1/
Unidades01a12-PPT.pdf (filmina 60).
Inicialmente los requisitos son creados y arrancan su ciclo de vida, el siguiente

paso es validarlo con los interesados, si obtenemos el OK de esa validación se
procede al desarrollo del mismo (Implementación) luego se lo verifica, para saber
si es correcto y ahí mismo finaliza el ciclo de vida. Por otra parte, si al validarlo
descubrimos que el requisito es real o no. Y puede dar origen a que ingrese a la
cola de espera de “Implementación”.
Actividad 1: ARMANDO UN PROCESO DE GESTION DE

LOS REQUISITOS
Actividad Se le solicita que piense y arme, basado en lo leído en estas

dos clases y en la lectura ampliatoria, un proceso de Gestión
de cambios los Requisitos para una empresa en particular
que se ocupa de desarrollar software para muchos clientes
distintos.
Lo que se espera es un flujograma del proceso. Mencionando
los pasos y los estados del pedido de cambio. Consideremos
solo el circuito básico, no uno que tenga cancelaciones.

clase 11
Actividad 1: ARMANDO UN PROCESO DE GESTION DE
REQUERIMIENTOS.
Si bien puede variar mucho dependiendo de la organización uno puede ser el
siguiente:

clase 11
conclusiones Lo que hemos visto hasta el momento nos permite comprender los grandes pasos
de la gestión de los requerimientos: estudiar la factibilidad, relevar a detalle,
validar, especificar teniendo en cuenta a todos los interesados y particularmente a
los desarrolladores. Sin éstos no podemos asegurar un proceso de relevamiento
de requisitos que cumpla con su objetivo.
A su vez vimos, que los requisitos tienen “estados”, digamos un ciclo de vida
propio, que nos permite conocer el estatus de cada uno y, por su puesto, armar
reportes para la gerencia o dirección.
Estos temas nos permiten armar un proceso de requisitos AD-HOC, pero
contemplando estos mínimos para garantizar su éxito.

clase 12 CONSIDERACIONES FINALES
introducción
En esta última clase vamos a ver dos temas relacionados con todo el análisis de
requerimientos, pero no necesariamente conectados entre sí.
El primero es el perfil que debe poseer un analista o ingeniero de requerimientos.
El segundo son buenas prácticas necesarias de tener en cuenta cuando llevemos

adelante tareas de relevamiento.
El Rol del Ingeniero de Requerimientos

clase 12
tema 1
Hasta ahora hemos tratado el tema de los requerimientos de las técnicas para
conseguirlos, analizarlos y verificarlos, del proceso para gestionarlos a ellos y
sus cambios. Ahora vamos a tratar el ROL y el PERFIL que deben tener aquellas
personas que se dediquen a estar tareas.
Veamos ambos conceptos:

ROL: es la función que desempeña una persona en un
lugar y situación determinado.
PERFIL: conjunto de cualidades o rasgos propios de una
Atención
persona o cosa.
Entendamos entonces, que el rol es el papel que juega la persona y que para
cumplirlo debe poseer ciertas competencias, habilidades, y ciertos conocimientos.
Pero ¿Cuáles serían? Veamos primero donde debe desenvolverse, como es el

entorno. El entorno en el cual debe desenvolverse lo podemos dividir en cuatro
grandes partes influyentes en el proceso de requerimientos.

¿Qué significa esto?
Negocio: hace referencia al negocio donde debe desempeñarse

el sistema.
Ingeniería de Software: hace referencia a la disciplina de

desarrollo de software.
Factor Humano: hace referencia al espacio “humano”, al conjunto

de personas con las cuales se debe interactuar.
Tecnologías de la información: hace referencia a las tecnologías vigentes

al momento del desarrollo.
Luego, el ingeniero de requerimientos debe moverse en estos ambientes,

donde debe realizar las siguientes tareas: recolectar, analizar, modelar/documentar
y validar las necesidades de los interesados. De cada uno de estos ambientes
debe poseer conocimientos, habilidades y técnicas.
Ing. de Software: debe tomar de aquí conocimientos como el ciclo de

vida del software para poder ubicar las tareas de la gestión de requerimientos.
Debe tomar de aquí las técnicas y los conocimientos de modelado. Ejemplo:
conocer UML para poder modelar los requerimientos con Casos de Uso.
Negocio: debe tomar de aquí el conocimiento del negocio y como

funciona, para poder comprender los requerimientos. Ejemplo: debe poder
comprender que es un impuesto y que es el IVA y como se administra para poder
comprender requisitos sobre un sistema de liquidación del IVA.
Factor Humano: debe tomar de aquí técnicas de gestión de las personas

y habilidades sociales que le faciliten las tareas, incluso conocimientos de
negociación. Por ejemplo: empatía, para facilitar el acercamiento y ganar confianza
del usuario, y poder así obtener un relevamiento más correcto y completo, sin
recelo y desconfianza por parte del usuario que produzcan información incompleta.
Tecnologías de Información y Comunicación: debe tomar de aquí

conocimientos de las tecnologías para poder comprender los requerimientos de
los interesados. Por ejemplo, conocer la tecnología de la web y los frameworks de
JavaScript para poder comprender un requerimiento de una aplicación web.

En resumen, las competencias deseables serían:
- Estar orientado al cliente
- Ser comunicativa y saber gestionar la comunicación
- Debe saber tomar decisiones
- Debe saber trabajar en equipo
Las habilidades:
- Poseer pensamiento sistémico
- Saber analizar
- Saber abstraer los conceptos
- Saber criticar e indagar
Es difícil que una persona posea este perfil completo, o puede que posea
algunos de sus componentes más desarrollados que otros. Una persona que
no lo cumple al perfil parcialmente no necesariamente debe ser rechazado
para el trabajo pero si al menos entrenado para superar los puntos flojos.
clase 12 Las Buenas Prácticas

tema 2
Los requisitos de software son importantes, los proyectos de sistemas pueden
fracasar si los requisitos no están bien relevados. Relevarlos bien es difícil,
existen prácticas que nos ayudan a hacerlo.
¿Cuáles son estas prácticas?
1- “Modelar junto al cliente” – entendemos aquí modelar los requisitos junto

al cliente, nos ayuda a intercambiar ideas y validarlos al mismo tiempo
que los modelamos, nos ayuda a garantizar el correcto entendimiento
del requisito. Ahora, requiere mucho tiempo del cliente y su disposición
a involucrarse. Es mucho más útil y eficiente irse de una reunión con un
modelo discutido que con una minuta en texto plano.
2- “Invertir mucho tiempo en descubrir los requerimiento” – Mientras

más tiempo invirtamos en descubrir y entender los requisitos mejor se
desarrollará el software.
3- “No documentar exhaustivamente si definimos buenos canales de

comunicación” – La documentación tiende a quedar desactualizada
rápidamente, más aun en contextos de requisitos cambiantes. Es mejor
tener buenos canales de comunicación pero teniendo siempre presente
la siguiente práctica:

4- “Privilegiar siempre la comunicación cara a cara” – sin escuchar ni ver es
muy fácil que se confunda el significado dado a las palabras.
5- “Definir un proceso y respetarlo” – Para poder tener un proceso ordenado

y medido.
6- “A mayor complejidad del requerimiento” – Ante requerimientos complejos

lo mejor es adoptar mayor flexibilidad para modelarlo. No sol flexibilidad,
sino descomposición en partes, “No podemos comernos un elefante de
un solo bocado”.
7- “Utilizar las herramientas que resulten sencillas” - de manera de facilitar

la colaboración del cliente en el modelado y comprensión.
8- “Tener en cuenta las restricciones socio-culturales” – Así como las

creencias y costumbres que puedan afectar la percepción del problema
por parte de nuestro interlocutor.
9- “Priorizar los requerimientos”: el cliente debe ser capaz de ordenar por

prioridades.
10- “Identificar si los requerimientos están basados en hechos o en creencias.”

Los primeros deberán ser prioritarios sobre los segundos (evaluar el
riesgo de avanzar con ellos).
11- “Sincerarse”: el requerimiento debe ser factible de realizar dentro de las

capacidades conocidas del sistema, modelar en detalle requerimientos
muy difíciles de ser implementados puede resultar en una total pérdida
de tiempo.
12- “Realizar un modelado iterativo e incremental” de los requisitos de

software: comenzar por un entendimiento general y entrar en detalles
cuando sea necesario para comprender una funcionalidad a implementar.
Actividad 1: Buenas prácticas
Resuelva el siguiente crucigrama:

Actividad

Actividad 2: WIKI - “Los requerimientos de software
y los del ‘proceso de negocio’ ”
Actividad Un tema muy habitual al realizar un relevamiento de los
requisitos para el desarrollo de un software es que los
usuarios quieren cambiar su forma de trabajar, por alguna
causa no están de acuerdo con el ‘proceso de negocio’ y
quieren aprovechar el cambio del sistema para cambiar
la forma de trabajar. Este cambio no necesariamente es
correcto, no necesariamente este validado por sus superiores
y no necesariamente respecta, políticas o leyes. Luego,
a veces los requerimientos que relevamos, analizamos y
luego verificamos correctos con los interesados terminan no
siendo correctos. Introducen cambios que no son aceptados
por todos, un interesado de más jerarquía lo frena.

Abordemos este tema de una forma colaborativa. Armemos, a través de una
Wiki, un conjunto de prácticas que nos permitan:
• identificar los interesados,
• discriminar si un requerimiento está pensado sobre un proceso

distinto al actual
• como validarlo y
• conseguir su ok.
clase 12
Actividad 1: Buenas prácticas
clase 12
conclusiones Es importante tener en cuenta que si no respetamos las buenas prácticas será
mucho más difícil lograr un buen relevamiento de los requerimientos, también
será más difícil lograrlo si la persona que lo realiza no tiene un perfil adecuado.
Mientras más nos acerquemos al perfil requerido y mientras más prácticas

implementemos más probabilidades de éxito vamos a tener.
Pero, tengamos en cuenta que el perfil y las prácticas no garantizan el éxito, sólo
lo favorecen.

Análisis de Requerimientos

Cargado por

Información del documento

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

Análisis de Requerimientos

Cargado por

Copyright:

Formatos disponibles

Instituto

TDS - Tecnicatura en Desarrollo de Software

impresión total del documento ! 146 páginas

ISP | Análisis de Requerimientos| Tercer Cuatrimestre 2

Para introducirlo en este mundo primero es necesario definir dos conceptos:

• Análisis, aunque sería mucho mejor expresarlo como un verbo dado

• ´Requerimiento’ petición de algo que se considera necesario.

Pero, nos falta una pata previa, el relevamiento. El concepto de relevamiento es

En esta materia vamos a estudiar cómo relevar y analizar los requisitos de

El relevamiento, análisis y especificación de los requisitos de los usuarios es

ISP | Análisis de Requerimientos| Tercer Cuatrimestre 3

- Conocer la importancia de los requerimientos para poder determinar su

Módulo 2: Relevamiento y Análisis de la información

ISP | Análisis de Requerimientos| Tercer Cuatrimestre 4

Módulo 4: Uniendo las partes e Informando los Requerimientos

Módulo 5: El proceso de Gestión de los Requerimientos

ISP | Análisis de Requerimientos| Tercer Cuatrimestre 5

• Sommerville, Ian (2011): Ingeniería de Software. 9° Edición. Pearson

• A lo largo de la asignatura se indican páginas web para realizar lecturas

ISP | Análisis de Requerimientos| Tercer Cuatrimestre 6

clase 1 QUÉ ES UN REQUERIMIENTO DE SOFTWARE Y LOS DISTINTOS TIPOS

Lo que buscamos en esta primera clase es introducirlo en el mundo de la Ingeniería

Los requerimientos son descripciones de lo que los interesados esperan que

El desafío de los requisitos es conseguirlos y que se acerquen al extremo de lo

También repasamos en el 2° tema de la clase la distinción entre Requerimiento

La obtención de los requerimientos es complicada, los usuarios no siempre

ISP | Análisis de Requerimientos| Tercer Cuatrimestre 7

Los clientes pueden participar del programa de Millaje. El canje

Este requisito es un requisito vago, muy orientado al usuario, y poco orientado al

Releamos la especificación anterior, ¿Cuál es el todo? Algo podemos ‘Suponer’:

Los clientes pueden participar del programa de Millaje. El canje

ISP | Análisis de Requerimientos| Tercer Cuatrimestre 8

Los clientes, categoría “gold label” pueden participar de

Excelente, el requerimiento se ha ido detallando; el analista finalizó su trabajo con

Los clientes, categoría “gold label” pueden participar de

ISP | Análisis de Requerimientos| Tercer Cuatrimestre 9

Los clientes, categoría “gold label” pueden participar de

Y luego, el analista pasa por el sector de atención de reclamos de Servicio al

Los clientes, categoría “gold label” pueden participar de

¿Qué sucedió aquí? Se fue detallando el requerimiento al ir descubriendo y

ISP | Análisis de Requerimientos| Tercer Cuatrimestre 10

El ‘todo’ antes mencionado es este dominio del software

Llegados a este punto ya tenemos en nuestras mentes el concepto de requisito

Para ampliar el contenido de este capítulo sugiero leer del

Actividad 1: Comencemos a trabajar en los requisitos

ISP | Análisis de Requerimientos| Tercer Cuatrimestre 11

Según la RAE, “Requerimiento” es un sinónimo de necesidad, es decir, un concepto

Avancemos, para entender los humanos clasificamos, clasifiquemos entonces,

Los requisitos tienen muchas clasificaciones, con categoría no excluyentes entre

• Requisitos del Usuario

• Requerimientos del producto

ISP | Análisis de Requerimientos| Tercer Cuatrimestre 12

Requisitos Funcionales: Son enunciados acerca de servicios que el sistema

Requisitos No-Funcionales: Son limitaciones sobre servicios o funciones que

2- Requisitos del Usuario y del Sistema:

Requisitos del usuario: “son enunciados, en un lenguaje natural junto con

ISP | Análisis de Requerimientos| Tercer Cuatrimestre 13

¿Diferencia? El nivel de detalle es lo primero que observamos y después, el

Actividad 2: Descubrir los Requisitos Funcionales y los

Trabajamos en el área de sistemas de una gran empresa dedica al retail.

ISP | Análisis de Requerimientos| Tercer Cuatrimestre 14

Los requisitos no funcionales, a su vez, pueden clasificarse en “Requisitos del

Los “requisitos de la organización” son aquellos derivados de las políticas y

Los “requisitos externos” son todos aquellos derivados de factores externos al