UNIVERSIDAD INTERNACIONAL

DE LAS AMERICAS

Rol del usuario en el desarrollo de sistemas

Profesor: Johanny Varela Ramírez, MAP.

1
¿Qué es un requerimiento?

2
Especificación y Análisis de Requerimientos

3
 ¿Qué es un requerimiento?

• Es un aspecto del contenido o comportamiento del producto,

requerido o deseado por el cliente.

• Requerimientos funcionales. (Debe hacer)

• Requerimientos no-funcionales.(Debe tener)

• Una restricción es un requerimiento que afecta a todo el producto.

4
 Ciclo de Vida “V”
Why? Concepto Verificación y Validación Pruebas acept.

What? Análisis Pruebas integ.

How? Diseño Pruebas unit.

Do! Código

Concepto : conocimiento general del proceso del negocio.

entrega: diag. de contexto, diag. de Entidad-Relación, Casos de Uso 5
 Fases de la especificación y análisis de
requerimientos
• Kickoff
• Recolección de requerimientos
• Prototipos
• Verificación y validación
• Revisiones
• Post-Mortem

6
 Kickoff
Preparación para el inicio del proyecto
• Reunión inicial entre los principales desarrolladores, clientes y
usuarios
• Principales resultados:
• El contexto
• Propósito del proyecto
• Lista de principales riesgos
• Estimación inicial del esfuerzo
• Decisión de seguir adelante o no
• Identificación clara de los interesados
• Compromiso con el proyecto
• Formación de equipos
7
 Propósito del producto / proyecto:

• Todos los demás requerimientos son verificados /

validados en torno a su contribución al propósito del
producto.
• Qué ventaja o solución queremos que ofrezca el
producto?
• El producto tiene un criterio de validación medible /
verificable.
• La satisfacción es un factor en el valor del producto.
8
Identificación de interesados
• Patrocinadores
• Clientes
• Usuarios
• Especialistas
• Ingeniero de requerimientos
• Entes reguladores
• Organización

9
Estimado inicial de costo / esfuerzo

• Primera medición del tamaño del

sistema:
• Número de sistemas adyacentes
• Cantidad de Entradas
• Cantidad de Procesos
• Cantidad de Salidas
10
 Evaluación y toma de decisión de seguir adelante

• Con base a lo anterior se analiza si:

• Los objetivos son viables y medibles?
• Son factibles?
• Son los riesgos demasiado altos?
• Es el costo de los objetivos razonable?
• Las personas implicadas están de acuerdo y
dispuestas?
• Se justifica el proyecto?
• Hay razones para cancelarlo? 11
 Recolección de requerimientos
Métodos
• Aprendiz
• Entrevistas
• Herramientas
• Mapas Mentales (Mind Maps)
• Lluvia de ideas (Brainstorming)
• Particionamiento del contexto
• Identificación de eventos y
Casos de uso
• Uso de Video 12
 Aprendiz
• La gente no siempre esta consciente de todas las tareas que realiza
"Nadie describe mejor lo que hace y por qué lo hace, que cuando lo
esta haciendo." [Beyer & Holtzblatt]
• El usuario generalmente no tiene tiempo para entrevistas

• El desarrollador se vuelve en el aprendiz de usuario, aprende su

trabajo por observación y preguntando.
• El aprendiz ve la misma tarea repetidamente
• El aprendiz demuestra lo aprendido haciéndolo bajo la supervisión
del usuario.
• Captura de eventos en tiempo real
• Retroalimentación inmediata
• Establece una relación con los usuarios y clientes 13
 Entrevistas
• Ir a ellos para entrevistarlos en su lugar de trabajo
• Explicar la razón de la entrevista
• Entrevistar primero al usuario más experimentado
• Preguntar, escuchar la respuesta y retroalimentar lo
entendido
• Utilizar la terminología del usuario
• Guardar ejemplares de documentos/artefactos
• Agradecer al usuario su tiempo
• Búsqueda de fallas potenciales: el requerimiento es
la falla establecida de forma positiva. 14
 Mapa Mental (Mind Maps)
• Diagrama usado para representar ideas o conceptos ligados a
una palabra clave o tema principal y que giran alrededor de
ella

• Es una imagen de distintos elementos utilizados como puntos

clave que brindan información de un tema o ramificación en
varios subtemas

• Útiles para extraer y memorizar información

• Son una forma lógica y creativa de organizar ideas, pudiendo

utilizar tipos de letras, colores, imágenes, links, marcadores
para organizar o estructurar la información 15
Mapa Mental (Mind Maps)

16
 Lluvia de Ideas (Brainstorming)
• El grupo de desarrolladores se reúne para una
lluvia de ideas
• Muchas ideas, ideas nuevas, toda idea es buena
• No deben evaluarse, debatir ni criticar
• No limitarse por lo posible
• Luego la lista de ideas es evaluada, ordenada
(votación)
-> 60 ideas locas pueden contener 5 ideas geniales.

17
Particionamiento del Contexto
• El problema principal se divide en contextos, unidades
discretas (desde el punto de vista del usuario)

• Cada contexto es un evento distinguible del problema

principal

• A cada participante se le asigna un contexto

• Se reutilizan los mecanismos de recolección de

requerimientos vistos anteriormente
18
Identificación de Eventos y Casos de Uso
• Los eventos se identifican por las entradas y
salidas del trabajo

• Los eventos son:

• algo que sucede fuera del trabajo y a lo que el
trabajo debe responder.
• Importante
• Reconocible
19
 Casos de Uso
• Porción de actividad: respuesta a un estímulo externo
o temporal
• Colección única de procesos y datos para cada evento
/ caso de uso
• Cada proceso se puede describir
• Cada evento / caso de uso tiene un número de
requerimientos funcionales y no-funcionales
• Algunos requerimientos no-funcionales se aplican a
todo el evento
• Utilícense los eventos como puntos de partida para
determinar los requerimientos, observaciones y
entrevistas.
20
 Uso de Video
• Grabar en video a los participantes y desarrolladores durante
las sesiones de brainstorming y talleres de casos de uso.

• Grabar las entrevistas y observaciones en el trabajo.

• Grabar la rutina realizada por los usuarios.

• Grabar a los usuarios durante su trabajo (ellos describen cómo

lo realizan).

• Registro detallado de las prácticas de los usuarios, grabar cada

evento y/o caso de uso.
21
• Los videos son una ayuda en la búsqueda de requerimientos.
 Tipos de Requerimientos
• Restricciones globales

• Requerimientos Funcionales

• Requerimientos No Funcionales

22
 Restricciones globales
• Afectan a todo el producto y son determinadas por el usuario y
los que administran el proyecto / producto.
• Propósito del sistema
• El cliente
• El usuario
• Convenciones para la nomenclatura y las definiciones
• Hechos relevantes
• Restricciones del proyecto
• Suposiciones

23
 Requerimientos Funcionales
• “Los requerimientos funcionales son las
descripciones explícitas del comportamiento que
debe tener una solución de software y que
información debe manejar” BABOK (Business Analysis Body of
Knowledge, pág. 16)

• Es lo que el producto debe hacer

• Alcance del sistema
• Funcionalidad del proyecto / producto
• Capacidades o cualidades que debe tener la solución para
satisfacer los requerimientos
• Descripción detallada para permitir el desarrollo e 24
implementación
 Requerimientos Funcionales
• Dentro de los requerimientos funcionales se
puede considerar:
• Los datos que deben ingresar al sistema
• Las operaciones que debe realizar el sistema, utilizando los datos
de entrada
• Flujo de trabajo de las operaciones, su secuencia ordenada y
lógica
• Generación de datos de salida producto de los flujos de trabajo
• Usuarios que interactúan con el sistema
• Cualquier regulación o norma que se deba considerar para la
construcción del sistema así como para la ejecución de los flujos
de trabajo 25
 Requerimientos Funcionales
• Describir una acción que debe realizar el producto

• No escribir soluciones

• Cada evento/caso de uso tiene muchos requerimientos

funcionales

• Algunos son parte también de otros eventos

• El uso del formato ayuda para determinar qué tan completa

está la especificación de requerimientos.
26
Ejemplos Requerimientos Funcionales
• El sistema enviará un correo electrónico cuando se registre
una transacción de pedido de venta al cliente, despacho de
mercadería al cliente, emisión de factura al cliente
• El sistema permitirá a los usuarios autorizados el ingresar
planes y cronogramas de proyecto
• El sistema debe poder emitir los siguientes estados
financieros: Balance General, Estado de ganancias y pérdidas,
Estado de flujos de efectivo
• El campo nombre acepta caracteres alfabéticos únicamente
• El sistema controlará el acceso y permitirá solamente a
usuarios autorizados
• La base de datos se implementará con trazas de auditoría 27
 Requerimientos No-Funcionales
• “No se relacionan directamente con el comportamiento de la
funcionalidad de la solución, sino describir las condiciones bajo las
cuales debe permanecer una solución efectiva o cualidades que debe
tener una solución” BABOK (Business Analysis Body of Knowledge, pág. 16)

• Se les llama también atributos de calidad. No determinan el

funcionamiento del sistema, pero aseguran que el cliente perciba el
sistema como más eficiente o valioso

• Apoyan a las funciones, son las propiedades que el producto debe tener
• Apariencia y sensación
• Usabilidad
• Eficiencia / Rendimiento
• Operabilidad
• Mantenibilidad
• Seguridad
28
• Requerimientos Políticas
• Requerimientos legales
 Requerimientos No-Funcionales
• Describen las propiedades o características que el producto debe tener.

• Cada requerimiento funcional tiene asociados requerimientos no-

funcionales

• Algunos pueden afectar a nivel de eventos, otros a todo el producto.

• Están más asociados hacia temas de calidad del producto

• Se relacionan con los gustos, preferencias y aspectos adicionales que el

producto debe satisfacer en las preferencias del cliente

29
 Requerimientos No-Funcionales
• Requerimientos no-funcionales:
• Apariencia y sensación: (Bosquejos)

• Usabilidad: Depende de la definición de los usuarios, cuantificable

por los criterios de evaluación.

• Performance: Requerimientos reales del performance, velocidad,

precisión, disponibilidad, seguridad, nivel de servicio, volúmenes de
datos, etc.

• Operacional: Ambiente en el que el usuario operará el producto y

productos con los que colabora.

• Mantenibilidad: Tiempo esperado y tiempo permitido para realizar

cambios de mantenimiento, portabilidad. 30
 Requerimientos no-funcionales

• Seguridad: requerimientos para permitir el acceso, pruebas de

integridad para prevenir mal -uso no intencionado por usuarios
autorizados, auditorías para detectar mal-uso, recuperación
después de un error, prueba de integridad después de un hecho
anormal. Considerar involucrar a un experto en seguridad.

• Políticas: Factores que podrían hacer al producto inaceptable por

razone políticas, este requerimiento puede no ser medible, puede
ser especificado como restricción.

• Aspectos legales: Examinar sistemas adyacentes, considerar sus

requerimientos y derechos legales, cite leyes relevantes al
producto, contar con el apoyo de abogados, restricciones
impuestas por estándares.
Ejemplos Requerimientos No Funcionales

• El sistema debe ser capaz de procesar N transacciones por

segundo (Eficiencia)
• Todas la comunicaciones externas entre servidores, aplicación
y usuarios deben estar encriptadas con algoritmo RSA
(Seguridad)
• El sistema debe contar con manuales de usuario (usabilidad)
• El sistema debe contar con un módulo de ayuda en línea
(usabilidad)
• El sistema debe considerar los lineamientos contables
aplicados por las leyes de hacienda (Legales)
• El sistema debe contar con pantallas emergentes para la
selección de valores de entrada (Apariencia) 32
 Registro de requerimientos
• Para manejar los requerimientos, estos deben tener:
• Un número único de ID
• Tipo
• Lista de los eventos y casos de uso que lo contienen.
• Descripción: una frase que describe la intención del
requerimiento.
• Propósito: Por qué se considera importante?
• Fuente: ¿Quién determinó este requerimiento

33
 Registro de requerimientos
• Dependencias: requerimientos que usan la misma información o que
ocasionan cambios.

• Conflictos: requerimientos que están en conflicto con este

• Materiales de apoyo: Indicación a las definiciones y documentos que lo

ilustran.

• Historia: Creación, cambios y eliminación

• Un requerimiento puede estar relacionado a varios eventos

• Requerimientos globales se relacionan a todos los eventos

34
 Registro de requerimientos
• Criterio de evaluación: Prueba no-ambigua que indica
si una solución cumple este requerimiento

• Satisfacción del cliente: Grado de satisfacción si el

criterio se cumple exitosamente (1 = no importa
mucho, 5 = muy satisfecho)

• Insatisfacción del cliente: Grado de insatisfacción si el

criterio no se cumple (1 = no importa mucho, 5 = muy
molesto)
35
 Restricciones
• Restricciones globales son las propiedades que aplican a
todo el producto

• Esta parte de la especificación probablemente será

escrita por la administración del proyecto.
• Propósito del sistema
• El cliente para el producto
• Usuarios del producto
• Convenciones de nomenclatura y definiciones
• Hechos/datos relevantes
• Restricciones del proyecto
36
• Suposiciones
 Restricciones
• Para las convenciones de nomenclatura se sugiere el uso de los diccionarios estándar
nacionales/internacionales para la industria

• Buenos nombres son fácilmente distinguibles y no requieren muchas explicación

• Cada nombre deberá tener una definición

• Deben definirse todas las abreviaturas, términos y siglas

• Hechos / datos relevantes: Están conformados por fuerzas, sistemas, actividades del
mundo externo que pueden tener efecto en el producto

• Se identifican cambios que deben tomarse en consideración

• Cambios probables en las fronteras del producto

• Cambios tecnológicos, a otros productos, en la estructura organizacional, al sistema 37

legal, políticas, etc,
 Restricciones del Proyecto
• Tecnológicas, de presupuesto, tiempo, etc. razones
por las que se restringe la manera en que se crea el
producto.

• Siempre indagar el por qué de estas restricciones y

anotar todas las restricciones y sus razones para el
producto.

38
 Verificación y Validación de Requerimientos

• Prevenir la infiltración de requerimientos: los que entran al

producto después del proceso de análisis de requerimientos.
• Prevenir la fuga de requerimientos: aquellos cuya fuente se
desconoce
• Estos incrementan desmesuradamente el costo y el tamaño
del producto.
• Se pueden usar métricas de función para controlar la
infiltración de requerimientos.
• El número de function points puede ser una medida para
limitar el tamaño del desarrollo.
39
 Prototipos
• Se refiere a un producto que muestra la funcionalidad actual,
pero no tiene toda la lógica, funcionalidad y calidad que
tendrá el producto final

• Cuenta con características limitadas y en cada interacción se

pueden afinar o bien agregar otras

• Es de utilidad para ver como evoluciona el producto /

proyecto y brindar retroalimentación

• Permite validar que se cumpla con las necesidades del cliente

• Requiere más esfuerzo y recursos por sus interacciones 40

 Calidad de los requerimientos

• Evaluación de los requerimientos

• Para incluirlos en la especificación cada requerimiento debe pasar el

umbral de calidad.

• Sirve para prevenir la infiltración y la fuga de requerimientos.

• Los requerimientos rechazados se regresan al interesado

• Ser mantendrá una lista de requerimientos rechazados y la razón

41
 Calidad de los requerimientos

• Para pasar debe :

• Tener un criterio de evaluación
• Tener una identificación única y referencias a los eventos y casos
de uso
• Ser relevante
• Ser viable
• Tener un valor para el cliente
• No ser adorno
• Estar completo
• Usar la tecnología correcta

42
 Criterios de Validación

• Es una meta numérica que la solución debe cumplir

• No se puede diseñar una solución a un

requerimiento sin una manera de saber si se ha
logrado resolverlo o no

• Para los requerimientos funcionales el criterio

especifica cómo establecer si cumple sus objetivos

• Para los requerimientos no-funcionales cuantifican

el comportamiento resultante. 43
 Métricas

Tipo de requerimiento Escalas de evaluación

Apariencia y sensación Cumple con el estándar?
Especificar quién/cómo probarlo
Usabilidad Tiempo requerido para aprender
Tiempo de entrenamiento
Realización de funciones en tiempo
planteado
Performance Tiempo para completar la acción
Operabilidad Cuantificación del tiempo/facilidad de
uso
Mantenibilidad Tiempo permitido
Esfuerzo requerido para portarlo
Seguridad Cuantificar quién ha tenido acceso
Requerimientos Políticas Quién los acepta (no son cuantificables) 44
Requerimientos legales Opinión del abogado
 Prueba de los criterios

• Cumple con los objetivos y la intención del producto?

• Provoca el comportamiento correcto?

• Puede ser probado?

• Las pruebas son eficientes (costo)?

• Es subjetivo el criterio?

• Esta definida la terminología?

45
• Es ambiguo?
Pruebas de viabilidad

• Los usuarios son capaces de usar el producto?

• Tenemos la habilidad tecnológica para construir el

producto?

• Se tienen los medios y el tiempo para ello?

• Es aceptable a todos los interesados?

• Se puede hacer de manera eficiente?

46
• Cuáles son las consecuencias del requerimiento?
 Revisión de Requerimientos
• Después de escribir la especificación de requerimientos se
debe realizar una revisión, para asegurar la calidad y
completez de la especificación

• Hasta este punto los requerimientos individuales ya pasaron el

punto de control de calidad (quality gateway)

• La revisión de la especificación busca requerimientos

faltantes, checa consistencia, conflictos y ambigüedad

• Uso de un filtro de requerimientos (conjunto de reglas para

determinar si los requerimientos van conforme a la
especificación
47
• Análisis de riesgos
Revisión de Requerimientos
• Determinar el esfuerzo contando function points por cada
evento/caso de uso

• Determinar el valor para el cliente (suma de los valores de

satisfacción del cliente)

• Mantener una base de datos de los requerimientos

rechazados

• Realizar un post-mortem al proceso de requerimientos

48
• El proceso de revisión es iterativo hasta que se resuelven
todas las inconsistencias, conflictos y ambigüedades
 Post-Morten
• Aprender de las experiencias anteriores: Mejoramiento
continuo del proceso
• Permite analizar las oportunidades de mejora y definir como
cambiar las prácticas en el siguiente ciclo
• Evaluar el producto producido, esfuerzo invertido y el proceso
seguido para hacerlo realidad
• Se requiere de la participación de los involucrados directos en
el proceso, con los datos que se han recopilado
• El equipo se reúne, comparte información, identifica en donde
el proceso funcionó y en donde no y qué no funcionó, se
proponen mejoras que se ponen en práctica en el siguiente
ciclo 49
 Modelado de Requerimientos
• Modelos de Contexto
• Diagrama de contexto: Punto de partida para todo modelado
• Representa al sistema y sus conexiones al mundo exterior.
• contienen: sistema, sistemas adyacentes y la información que
provee cada uno o los datos que fluyen entre el sistema y cada uno
de los sistemas adyacentes.
• Cada proceso se escribe dentro de un círculo que recibe datos,
transfiere datos a otro proceso o sistema adyacente o los
almacena, su nombre refleja el proceso que realiza.
• Almacenes de datos se dibujan con dos líneas paralelas
horizontales.
• Por convención no se muestran flujos de 'tiempo'
50
 Trabajo en Clase:
Caso 1 Toma de Requerimientos

51
 Ej. Sistemas a seleccionar
• Ventas en línea
• Reservas (hospedaje, ej.: Airbnb)
• Tiquetes de atención requerimientos (mesa de ayuda)
• Quejas de servicios
• Transporte personas (ej.: Uber, Didi)
• Comidas
• Chats (ej.: Twitter, Instagram)

• Mínimo 25 requerimientos por grupo

52