Este documento presenta una introducción a la ingeniería de requerimientos. Explica que la ingeniería de requerimientos involucra el descubrimiento, documentación y mantenimiento de los requerimientos para un producto. También cubre la importancia de los requerimientos, el ciclo de vida de los requerimientos, las propiedades deseables de los requerimientos, y técnicas comunes para la extracción y documentación de requerimientos.

1. Ingeniería de Requerimientos
Parte I
4 September 2017

2. Contenido
• Introducción
• Importancia de los requerimientos
• Ciclo de vida de requerimientos
• Propiedades de los requerimientos
• Errores de requerimientos
• Clasificaciones de requerimientos
• Documentación de requerimientos
• Trazabilidad de requerimientos
• Gestión de requerimientos
• Conclusiones

3. 3
La realidad de los
Requerimientos

4. Introducción
• Conjunto de actividades involucradas
en el descubrimiento, documentación
y mantenimiento de los
requerimientos para un producto
determinado – según Ortas 1997
• El proceso de recopilar, analizar y
verificar las necesidades del cliente
para un sistema, es llamado Ingeniería
de Requerimientos. La meta es
entregar una especificación de
requerimientos de software correcta y
completa

5. Introducción
• La Ingeniería de requerimientos
comprende todas las tareas
relacionadas con la determinación de
las necesidades o de las condiciones a
satisfacer para un software nuevo o
modificado, tomando en cuenta los
diversos requerimientos de los
usuarios, que pueden entrar en
conflicto entre ellos. Puede ser
conocida también como "Análisis de
requerimientos", "especificación de
requerimientos", etcétera

6. Introducción
¿Qué es un Requerimiento?
• Una condición o capacidad necesaria
para un usuario para resolver un
problema o alcanzar un objetivo
• Una condición o capacidad que debe
estar presente en un sistema o
componentes de un sistema para
satisfacer un contrato, estándar,
especificación u otro documento
formal
• Una representación documentada de
una condición o capacidad como en (1)
o (2)

7. Importancia de los
requerimientos
“La parte más difícil de construir un
sistema es precisamente saber qué
construir. Ninguna otra parte del trabajo
conceptual es tan difícil como establecer
los requerimientos técnicos detallados,
incluyendo todas las interfaces con
gente, máquinas y otros sistemas.
Ninguna otra parte del trabajo afecta
tanto el sistema si es hecha mal. Ninguna
es tan difícil de corregir más adelante...
Entonces, la tarea más importante que el
ingeniero de software hace para el
cliente es la extracción iterativa y el
refinamiento de los requerimientos del
producto.”
Frederick P. Brooks 1987

8. Importancia de los
requerimientos
• Los requerimientos se deben descubrir
antes de empezar a construir un
producto y puede ser algo que el
producto debe hacer o una cualidad
que el producto debe tener
• Si no se tienen los requerimientos
correctos, no se puede diseñar o
construir el producto correcto

9. Modelo General
9
Gestión del Portafolio y Proyectos
Estrategia y
Demanda
Operacional
Definición y Gestión de Requerimientos
Elicitación
Análisis
Especificación Validación
Priorización, Verificación,
Riesgo, Estimación
Priorización, Verificación,
Riesgo, Estimación
Requerimientos detallados,
Escenarios de modelos de negocio,
Modelos de casos de uso, Prototipos
Técnicas, Interesados,
Glosarios, Límites del sistema
Gestión de Requerimientos
Almacenamiento, Trazabilidad, Medición y Auditoría, Estado, Documentación, Seguridad

10. 10
Flujo General

11. Modelo en
Cascada
11

12. Ciclo del Análisis
de
requerimientos
12

13. Extracción de
Requerimientos
• Existen diferentes métodos para la
extracción de los requerimientos.
Algunos son:
• Entrevistas con el cliente y con los
futuros usuarios
• Encuestas
• Documentos entregados por los
clientes
• Prototipación
• Sistemas antiguos

14. Extracción de
Requerimientos
• Es importante tener en cuenta que en
muchos casos el cliente no sabe al
inicio del proyecto cuales son sus
requerimientos.
• En este sentido es más un proceso de
definición y descubrimiento de
requerimientos junto al cliente que
una extracción de algo existente

15. 15
Un Poco de
Humor

16. Entrevistas y reuniones
• Publicar previamente una agenda y seguirla
• Incluir a las personas apropiadas
• Si no se invita a una reunión a un
actor importante para los temas
tocados, tenderá luego a asistir a
todas las reuniones para no perder
nada
• Si se invita alguien que en la práctica
no tiene relación con el tema de la
reunión, puede distorsionar la reunión
y no asistir a reuniones posteriores
• Manejar las personas que no pertenecen a
la reunión
• No agendar reuniones justo antes de la hora
de almuerzo
• Procurar se respeten los horarios de inicio y
término de las entrevistas y reuniones

17. Entrevistas y reuniones
Llevar tarjetas de presentación y presentarse al inicio de la entrevista si no lo ha hecho
anteriormente con algún participante
Recordar y confirmar la asistencia de los participantes claves a la reunión unos minutos
antes de la hora de inicio
Establecer previamente una política de interrupciones
Prohibir ataques personales y descalificaciones
Reducir la presión si la atmósfera de la reunión se complica, pero considerando que de
algunos conflictos pueden surgir conclusiones importantes para el proyecto

18. Entrevistas y
reuniones
• Al hacer una pregunta, escuchar la
respuesta, entonces describir nuestro
entendimiento
• Usar la terminología y artefactos del
usuario
• En los minutos finales, revisar los
puntos tocados en la entrevista o
reunión para detectar detalles que
necesitan aclaración “en caliente”
• Al termino, agradecer a los usuarios
por su tiempo y hacerle saber por que
fue valiosa su participación
• Luego, confeccionar una minuta
incluyendo los compromisos
resultantes y enviarla a los
participantes para su visto bueno

19. Análisis comparativo
de algunas técnicas
19
Técnica
• Entrevistas y Cuestionarios
Ventajas
• Se obtiene una gran cantidad de información
correcta del usuario
• Pueden usarse para obtener un pantallazo del
dominio del problema
• Son flexibles
• Pueden combinarse con otras técnicas
Desventajas
• La información obtenida al principio puede ser
redundante o incompleta
• Si el volumen de información manejado es
alto, requiere mucha organización de parte del
analista, así como la habilidad para tratar y
comprender el comportamiento de todos los
involucrados

20. Análisis comparativo
de algunas técnicas
20
Técnica
• Lluvia de Ideas
Ventajas
• Los diferentes puntos de vista y las
confusiones en cuanto a terminología,
son aclaradas por expertos
• Ayuda a desarrollar ideas unificadas
basadas en la experiencia de un
experto
Desventajas
• Es necesaria una buena
compenetración del grupo participante

21. Análisis comparativo
de algunas técnicas
21
Técnica
• Prototipos
Ventajas
• Ayudan a validar y desarrollar nuevos
requerimientos
• Permite comprender aquellos
requerimientos que no estén muy claros y
que sean de alta volatilidad
Desventajas
• El cliente puede llegar a pensar que el
prototipo es una versión del software que
será desarrollado
• A menudo, el desarrollador hace
compromisos de implementación con el
objetivo de acelerar la puesta en
funcionamiento del prototipo

22. Análisis de
requerimientos
• Se procesa la información obtenida
• Se analizan inconsistencias que
puedan existir
• Se analiza si la información obtenida
es suficiente para la etapa de diseño

23. Documentación de
Requerimientos
• Los diferentes tipos de documentos
son: User Requeriment Specification
(URS), Alternatives and Impacts
Document (AID), Software
Requirements Specification (SRS),
Prototipos
• Es importante que los documentos
estén completos
• Estos documentos no solo sirven para
saber qué hay que hacer sino para
tener un respaldo validado por el
cliente de lo que posteriormente se
construye

24. 24
Modelo Ciclo de
Vida

25. Revisión de los
requerimientos
• Proceso manual que involucra a varios
lectores
• IQA: revisión interna del proyecto
• EQA: revisión externa del proyecto
pero interna a la empresa

26. Validación de
Requerimientos
• El equipo “conduce” al cliente a través
de los requerimientos para confirmar
si es lo que realmente quiere
• Es muy importante que el cliente
valide los documentos generados

27. Proceso de
lectura
El proceso de lectura consiste en leer la secuencia de
letras de cada palabra y luego ir armando la frase con
cada una de las palabras identificadas
Según un etsduio de una uivennrsdiad ignlsea no
ipmotra el odren en el que las ltears etsen ersciats, la
uicna csoa ipormnte es que la pmrirea y la utlima ltera
esten ecsritas en la psiocion cocrrtea. El rsteo peuden
estar taotlmntee mal y aun prodas lerelo sin pobrleams.
Etso es pquore no lemeos cada ltera en si msima, pero si
la paalbra cmoo un todo.
¿No te parcee aglo icrneible?

28. Propiedades
Identificaremos algunas
propiedades deseables de los
requerimientos del software
Propiedades que deben tener
todos los requerimientos para
estar bien especificados
Al inspeccionar los
requerimientos deben
considerarse estas propiedades
(utilizar cuestionarios de
validación para inspeccionar
requerimientos)

29. Clasificación de
Propiedades
• Dos tipos de propiedades de
requerimientos:
• Propiedades globales:
• Completitud
• Consistencia
• Propiedades individuales:
• Tamaño
• Claridad
• Comprobabilidad
• Condiciones de error
• Trazabilidad

30. Tamaño
• Para manejar con mayor facilidad un
requerimiento, deberá tener un
tamaño adecuado:
• Ni tan grande que sea
inmanejable
• Ni tan pequeño que no valga la
pena seguirle la pista por
separado
• Es posible aplicar los principios de
modularidad y anidamiento a los
requerimientos

31. Completitud
• Significa que no hay omisiones que
comprometan la integridad de los
requerimientos
• No faltan requerimientos (propiedad
global)
• No faltan detalles en la especificación
de cada requerimiento (propiedad
individual)
• Es una propiedad difícil de determinar
(tan sólo podemos alcanzar una
aproximación)
• Se aconseja para lograr completitud
de requerimientos:
• Contrastar con el cliente
• Comparar con proyectos
semejantes

32. Consistencia (o
coherencia)
• Significa que no hay contradicciones
entre requerimientos (ni
acoplamientos/redundancias).
• Contradicción – Ambigüedad: las
ambigüedades dificultan detectar
contradicciones
• Es más difícil de comprobar si el
número de requerimientos crece
• Una buena organización facilita la
detección de contradicciones (por
ejemplo utilizando una tabla de
referencia cruzadas)

33. Consistencia: Tabla de Referencia
Cruzadas
• La detección de contradicciones
• La detección de requerimientos afectados por la modificación de uno dado
Sirve para:
• Conflicto: contradicción, no se pueden satisfacer simultáneamente
• Acoplamiento: hablan de lo mismo (si cambia uno, puede afectar al otro)
• Redundancia: dicen lo mismo (sobra uno de los dos)
• Independencia
Dos requerimientos pueden relacionarse como:
En la versión final no puede haber conflictos ni redundancias, sí acoplamientos

34. Claridad
• Significa que no hay ambigüedad en la
especificación de cada requerimiento
• Es conveniente utilizar un vocabulario
controlado, y tabla de términos equivalentes
(sinónimos)
• Para cualquier labor de documentación
• Tener siempre a mano diccionarios
(normal, sinónimos, estilo, idiomas,
corrector ortográfico y sintáctico)
• Escribir, corregir, escribir, corregir… y
hacerlo entre varios (uno escribe, otro
corrige)
• Respetar normas ortográficas,
sintácticas, gramaticales, de estilo
• Estructurar bien, proceder con orden,
proporcionar las referencias necesarias
• Sintetizar, resaltar ideas importantes,
resaltar más lo menos obvio

35. Comprobabilidad
• Incluye dos tipos distintos de defectos que se
desea descubrir y eliminar:
• Validación: defectos de interpretación
• Verificación: defectos de
implementación
• Muchos defectos se pueden descubrir y
eliminar mediante pruebas, pero salvo que se
usen métodos formales, las pruebas no
garantizan que todos los defectos
desaparezcan
• Las pruebas de verificación no sirven como
pruebas de validación
• Para validar y verificar un requerimiento es
necesario que éste sea comprobable
(testeable)
• Un requerimiento no comprobable o ambiguo
tiene escaso valor y debe ser rechazado.

36. Comprobabilidad:
Ejemplos
• Ejemplo:
• El sistema mostrará la diferencia entre
el valor observado y la media mundial
(no comprobable)
• El sistema mostrará la diferencia entre
el valor observado y el valor publicado
por Naciones Unidas (¿cuándo? todavía
es ambiguo)
• El sistema mostrará la diferencia entre
el valor observado y el último valor
publicado por Naciones Unidas en su
página web (conviene asegurar que no
es ambiguo, ni siquiera si se
interpretase mal a propósito)
• Esbozar una prueba específica que establezca
la satisfacción
• La definición de pruebas ayuda a clarificar el
sentido de cada requerimiento
• Condiciones de error

37. Problema: Sistema
de inventario
• Mantener el saldo de los artículos de
la empresa
• Registrar la recepción y salida de
artículos en las bodegas los
movimientos entre ubicaciones de la
misma bodega
• Obtener la lista de artículos y su saldo
disponible por familia y posición
• Obtener la lista de artículos y su
posición por fecha de vencimiento
menor que una fecha dada
• Encontrar la ubicación de un artículo
particular con fecha de vencimiento
más próxima

38. Problema: Sistema de
inventario
Restricciones
• La ubicación responde a los requisitos
definidos para cada artículo
(temperatura, exposición solar,
humedad)
• En una misma ubicación de la bodega
no se pueden ubicar ítems con
distinto número de lote/fecha de
vencimiento
• Los ajustes de saldos de stock se
pueden realizar solo por los
responsables de las secciones en las
bodegas
• En las transacciones se debe poder
identificar los artículos por su código
de barra
• Todos los reportes se deben poder
exportar a MS Excel

39. Problema: Sistema de
inventario
Ambigüedades
• ¿”Ubicación” y “posición” son lo
mismo?
• ¿Cuál es el saldo de un artículo?
¿Existe un único tipo de saldo de
artículos?
• ¿Los artículos en tránsito de una
bodega a otra aparecen en el listado
de saldos?
• ¿Todas las recepciones y salidas son
iguales?
• ¿Con qué formato se deben exportar
los reportes a Excel?

40. Problema: Sistema de inventario
Incompletitud
¿Qué es un artículo y cuál es su información asociada?
¿Los artículos en tránsito de una bodega a otra qué posición tienen?
Las bodegas se organizan en secciones y las secciones en ubicaciones. Hay distintos tipos de
secciones (intemperie, techada, refrigerada, cuarentena y destrucción)
•Los artículos recibidos por compras no pueden vencer en menos de 6 meses y los que
salen por venta en menos de 3 meses
•Los artículos con control sanitario pendiente deben mantenerse en una sección
“cuarentena” en cada bodega y no pueden venderse
Restricciones perdidas

41. Distribución de errores en la especificación de requerimientos
41

42. Las consecuencias
de los problemas
Mas del 30% de todos los proyectos de
software son cancelados antes de su
finalización
Mas del 70% de los proyectos restantes
fallan al entregar y evaluar las
características esperadas
Un proyecto promedio ejecuta 189%
sobre el presupuesto aprobado y
extiende sus actividades sobre el 222%
The Stadish Group · 1996

43. ¿Por qué los Proyectos de Software son exitosos?
15,9%:
involucra
a
usuarios
13,9%:
soporte
administr
ación
13,0%:
clara
definición
de
requerimi
entos
9,6%:
apropiad
o
planeami
ento
8,2%:
expectati
vas
realistas
7,7%:
hitos no
extensos
7,2%:
equipo
compete
nte de
profesion
ales
Quality
Systems
&
Software
· 1997

44. ¿Por qué los Proyectos
de Software fallan?
• 13,1%: requerimientos incompletos
• 12,4%: falta de requerimientos
• 10,6%: falta de recursos
• 9,9%: expectativas no realistas
• 8,7%: cambio de
requerimientos/especificaciones
• 8,1%: falta de planeamiento
• 7,5%: no se especifico el tiempo
adecuado
Quality Systems & Software · 1997

45. 0,15% 0,5%
7%
20%
60%
100%
0%
10%
20%
30%
40%
50%
60%
70%
80%
90%
100%
Requerimientos Diseño Codificación Test de desarrollo Test de
aceptación
Operación
Fase en la que se identifica el error
Costorelativo
Costos
relativos en la
corrección de
errores de
requerimient
os
45

46. Errores de
requerimi
entos

47. Errores de
requerimientos
• El 48% de los defectos observados en
proyectos de software de mediana
escala son “atribuidos a especificaciones
funcionales o requerimientos
incorrectos o mal interpretados” (Basili y
Perricone · 1984)
• El 79,6% de los defectos de las interfaces
y el 20,4% de los defectos de
implementación se deben a
requerimientos omitidos o incompletos
(Perry y Stieg · 1993)
• El 44,1% de todos los defectos de los
sistemas se producen en la etapa de
especificación (Computer Weekly Report
· 1994)
• La tecnología es un problema mayor solo
en un 7% de los proyectos

48. Errores de
requerimientos
• “Los requerimientos, especialmente
expresados en una especificación (o a
menudo no expresados porque no
existe especificación), son la mayor
fuente de los costosos bugs. El rango
va desde un pequeño porcentaje
hasta más del 50% dependiendo de la
aplicación y el ambiente. Lo que más
duele es que estos defectos son los
que más temprano invaden el sistema
y también son los últimos en salir. No
es raro que un requerimiento
defectuoso pase todos los tests de
desarrollo, el beta-test, y el uso inicial
en producción, sólo para ser
descubierto después de que se ha
instalado en centenares de sitios”
(Beizer · 1990)

50. Requerimientos Funcionales y
No Funcionales
• Los requerimientos se pueden dividir
en “Requerimientos Funcionales” y
“Requerimientos No Funcionales”
• Los requerimientos funcionales son
los requerimientos que especifican las
entradas (estímulos) al sistema, las
salidas (respuestas) del sistema y la
relación entre las entradas y las
salidas
• Los requerimientos no funcionales
tienen que ver con características o
restricciones que de una u otra forma
puedan limitar el sistema, como por
ejemplo, el rendimiento (en tiempo y
espacio), interfaces de usuario,
confiabilidad, mantenimiento,
seguridad, portabilidad, estándares,
etc.

51. Requerimientos Funcionales
Ejemplos
• Para calcular el interés de depósito
fijo anual, se hace por un período de 3
años al 14%
• Los datos requeridos de los clientes
son: nombre, apellido, CI y teléfono
• Para poder ingresar un cliente,
primero hay que tener ingresada la
empresa en la cual trabaja

52. Requerimientos No Funcionales
Ejemplos
Performante
• Número de dígitos de precisión en un
cálculo numérico
• Tiempo máximo de respuesta en una
transacción
• Tiempo de respuesta y finalización de
tareas en un sistema de tiempo real
Ambiente
• Que el sistema corra bajo un
determinado sistema operativo
• Usar un determinado lenguaje de
programación
Seguridad
• El alta y baja de libro puede ser
realizado solo por el jefe de librería

53. Requerimientos No Funcionales
Ejemplos
Usabilidad
• Los futuros usuarios deben poder
utilizar el sistema después de un
entrenamiento de 2 semanas
• El ingreso de pedidos de clientes
típico (15 ítems) no puede llevar más
de 1 minuto
Confiablidad
• Probabilidad de falla bajo demanda
(POFOD)
• Tasa de ocurrencia de fallas (ROCOF)
• Tiempo medio entre fallas (MTTF)
• Disponibilidad

54. Otros criterios de clasificación
de requerimientos
• Tipos de satisfacción en el cliente o usuario:
• Requerimientos Normales
• Respuestas del usuario a preguntas específicas
• La satisfacción / insatisfacción es proporcional a su
presencia / ausencia en el sistema
• La satisfacción es lineal y bi-direccional
• Requerimientos Esperados
• Tan básicos que es posible que el usuario no los mencione
• Su presencia en el sistema seguramente cumpla con las
expectativas del cliente pero no aumenta la satisfacción
• Su ausencia es muy insatisfactoria
• Requerimientos Extra
• Van mas allá de las expectativas de los clientes
• No son extraídos de los clientes
• Alta satisfacción de los clientes cuando estos
requerimientos resultan exitosos
• Su ausencia no insatisface porque no son esperados
• Tipos de servicio
• Categorías de usuario

55. Expectations
Fulfil
Exciting
Expected
Normal
Satisfaction
Dissatisfaction
Don't Fulfil
Expectations
Normales,
esperados
y extras
55

56. Tendencia a través
de los años
• Los requerimientos extra se están
transformando cada vez mas en
requerimientos normales
• Algunos requerimientos normales se
transforman en esperados

57. Clasificación por tipos de servicio
Requerimientos
asociados a
funcionalidad
Necesidades de
información del
usuario
Aspectos del
procesamiento de
la información
Requerimientos
asociados a
presentación
La manera o
forma de
presentar la
información
Requerimientos
asociados a
performance
Criticidad del
tiempo de la
información
Uso optimo de los
recursos
Requerimientos
asociados a
administración
Controles en el
procesamiento de
la información
Clima
organizacional

58. Clasificación por
categorías de usuarios
• Recopilar los requerimientos en
relación con cada categoría de
usuarios para asegurar la completitud
de los requerimientos

59. Documentos de requerimientos
URS · User Requirements
Specification
•Documento inicial que describe
cual es la funcionalidad del
negocio requerida y los
problemas existentes desde la
perspectiva del usuario.
•El URS documenta los objetivos
que se suponen deben ser
logrados y los requerimientos
asociados para alcanzarlos.
•Contenido: Introducción,
Descripción general,
Requerimientos, Plan de IT,
Apéndices
AID · Alternatives and
Impacts Document
•Las diferentes soluciones
alternativas y su impacto en la
organización o dominio del
cliente es definido en el AID
•Su principal propósito es servir
como un registro de que
distintas alternativas se
generaron durante el análisis y se
definió un ranking de acuerdo a
su impacto
•Puede ser o no entregado al
cliente
•Contenido: Introducción,
Soluciones alternativas,
Impactos, Solución elegida
SRS · Software
Requirements Specification
•Documento genérico de
especificación de
requerimientos.
•Contiene una descripción global
del sistema completo
•Puede estar mas o menos
detallado según los datos
obtenidos al momento
•Tiene que estar escrito de forma
que sea comprensible por el
usuario, ya que deberá validarlo
•Contenido: Introduction,
Purpose, Scope, Definitions,
acronyms and abbreviations,
References, Overview, Product
perspective (System Interface,
User Interface, Hardware,
Interface, Software Interface,
Communication Interface,
Memory Constraints, Operations,
Site Adaptation requirements),
Product functions, User
characteristics, Constraints,
Assumptions and dependencies,
Prioritizing of the requirements,
Specific requirements (External
interfaces, Functions,
Performance requirements,
Logical database requirements,
Design constraints, Software
system attributes, Organizing the
specific requirements, Additional
comments)
Prototipos
•El prototipado es una técnica de
construcción parcial del sistema
•En un comienzo, su objetivo era
que los clientes, usuarios y
desarrolladores pudieran
aprender más sobre un problema
o la solución del problema
•Entonces, la única y principal
función del desarrollo de un
prototipo era establecer los
requerimientos
•Es una manera muy fácil de
representar la navegabilidad y
presentación del sistema

60. Características de un
buen SRS
• Correcto
• No ambiguo
• Completo
• No poner frases como: “a definir”
(TBD – To be determinated)
• Verificable
• Consistente
• Modificable
• “Traceable”

61. Prototipos
• Esta técnica en general logra
conformidad del cliente
• La construcción de un prototipo
puede llevar muy poco código
• Es recomendable cuando el cliente
quiere ver resultados rápidos. Da
confianza al cliente
• Existen diferentes niveles de
prototipado. Estos pueden ser
básicos, intermedios o avanzados. La
diferencia se da en la cantidad de
detalles que se incluyan en el mismo y
esta ligado a la etapa del proyecto

62. Prototipos
• En un comienzo se diferenciaba el
concepto de prototipo y de
subconjunto
• Un subconjunto era también una
implementación parcial
• El propósito de un subconjunto era
proveer una funcionalidad de forma
temprana, mientras que el propósito
de un prototipo era aprender más
sobre un problema o su solución
• Actualmente el término prototipo se
utiliza para ambos casos
• En este sentido una clasificación para
prototipos es:
• Descartable
• Evolutivo

63. Prototipos
Descartable:
• El prototipo es construido para
aprender más sobre un problema o su
solución y es descartado luego que el
conocimiento deseado es logrado
• El sistema definitivo, utilizando el ciclo
de vida de desarrollo común, utiliza el
prototipo como un modelo, la
codificación comenzará de cero
• Este aprendizaje puede ser de los
desarrolladores o del cliente, ya que
sirve para mostrar posibles soluciones
al cliente
• En este sentido, el prototipo es
puramente un documento de
requerimientos, no va a ser la base
para el futuro sistema

64. 64

65. Prototipos
Evolutivo:
El prototipo es construido incorporando las funcionalidades principales
El usuario define la entrada utilizada para el refinamiento y mejora
El prototipo es refinado para alcanzar las necesidades mejor
comprendidas en ese momento
Los pasos 2 y 3 son repetidos hasta que el prototipo satisface todas las
necesidades y ha evolucionado por lo tanto a un sistema real

66. Ciclo de vida del desarrollo de
software utilizando un
prototipado evolutivo
66
ESPECIFICACIÓN DE
REQUERIMIENTOS
DESARROLLAR / REFINAR /
MEJORAR PROTOTIPO
UTILIZAR / EVALUAR
PROTOTIPO
¿SE ALCANZARON
COMPLETAMENTE LAS
NECESIDADES DEL
USUARIO?
LIBERAR COMO EL
SISTEMA DEFINITIVO
NO
SI

67. Variación de
prototipado evolutivo
Prototipación
incremental
67
ESPECIFICAR INCREMENTO
DEL SOFTWARE
CONSTRUIR INCREMENTO
DEL SOFTWARE
VALIDAR INCREMENTO
¿SE COMPLETÓ
EL SOFTWARE?
ENTREGA DEL SOFTWARE
COMPLETA
NO
SI
DEFINIR ENTREGABLES
DEL SOFTWARE
ENTREGAR INCREMENTO
DEL SOFTWARE

68. Comparación
68

69. Cuando se aplica
Aplicar prototipado cuando el sistema
es:
• Dinámico
• Extensivo en diálogos con el usuario
• En línea
No aplicar prototipado cuando el sistema
es:
• Estable
• Batch
• Hace poca utilización de diálogos con
el usuario
• Hace uso extensivo de cálculos
matemáticos

70. Técnicas de Documentación
Casos de Uso
•Es una especificación muy
detallada de la
interacción entre el
sistema y el usuario
•Se debe tener en claro
que este documento será
de vital importancia para
las futuras etapas del
proyecto
•Existen diferentes
formatos para la
documentación de casos
de uso
•Es común que exista mas
de un caso de uso por
cada requerimiento
funcional
•Pueden ir asociados con
un bosquejo de pantalla y
esto resulta muy
beneficioso
•En los casos de uso es
donde se describe cada
entrada y salida que debe
existir
Diagramas de Casos de
Uso
•Para establecer los
vínculos entre casos de
uso
•Sirven para visualizar las
relaciones entre actores y
casos de uso
•En estos diagramas
también se involucran a
los diferentes actores del
sistema
Diagramas de estados
•Los diagramas de estados
describen el
comportamiento
dinámico del sistema en
respuesta a estímulos
externos
•Los diagramas de estados
son especialmente útiles
en modelar secuencias de
interacciones, como los
cambios de estado son
disparados por eventos
específicos
•Una actividad en un
“Estado” va a permanecer
en dicho estado (pasivo)
hasta que una condición y
una acción fuerce ir a otro
“Estado”
•Un diagrama de estados
puede estar solo en un
estado en un instante
dado
Matrices, Tablas y
Árboles de Decisión
•Son muy eficientes
cuando existe un gran
número de condiciones
ligadas unas con otras
•Son un complemento que
en muchos casos resulta
esencial para aclarar el
gran número de
condiciones a manejar
Pseudocódigo
•Es una descripción en
lenguaje natural
esquemática de lo que
debería hacer el sistema
•Método poco usado para
especificar la totalidad del
sistema
•Es beneficioso para
especificar ciertas partes
no muy claras del sistema
•Puede ser un buen
complemento de los
casos de uso si estos no
resultan suficientes para
transmitir las necesidades
del cliente

71. Casos de Uso (UC)
• Ejemplo de Formato:

72. Diagramas
de Casos
de Uso
72

73. Diagramas
de estados
73

74. Comparación
74

75. Ejemplo de árbol de
decisión
Reglas para facturación de la electricidad
• Si la lectura del medidor es “OK”,
calcular en base al consumo
• Si la lectura del medidor aparece
“baja”, entonces chequear que la casa
está ocupada. Si la casa está ocupada
calcular en base al consumo promedio
de la estación actual. De lo contrario,
calcular en base al consumo. Si el
lector está dañado, calcular en base al
máximo uso de electricidad posible

76. Ejemplo
de árbol
de
decisión
76

77. Tipos de tablas de decisión
Binarias
• Condiciones: Si o No
Tablas
Multivaloradas
• Las condiciones
pueden tener varios
valores
• Ejemplo:
• E = Empleado
• T = En
Entrenamiento
• S = Socio

78. Ejemplo de tabla de
decisión
El cálculo de facturación de electricidad
depende del tipo de cliente
• Si el cliente utiliza la electricidad para
fines domésticos y el consumo es
menor a 300 unidades por mes
entonces facturar con los cargos
mensuales mínimos
• Clientes domésticos con consumo de
300 unidades o más son facturados a
la tarifa especial.
• Usuarios de electricidad no
domésticos son facturados con tarifas
el doble que los usuarios domésticos
(tarifa mínima y especial son ambas
duplicadas)

79. Tabla de Decisión
• Tipo de tarifa a aplicar

80. Pseudocódigo
Ejemplo
Si el cliente selecciona la opción “Grabar
Temporal” entonces
Modificar estado a “Temporal”
De lo contrario
Modificar el estado a “Definitivo”
Fin

81. Trazabilidad
La evidencia de una asociación
entre un requerimiento y su
requerimiento fuente, su
implementación; y su verificación.
¿Para qué se utiliza la
trazabilidad?
Dado un requerimiento,
¿qué necesidad de la
misión del proyecto
satisface? (Es decir, ¿en
qué requerimiento
fuente se basa?)
¿Dónde está
implementado un
requerimiento
determinado?
Dado un requerimiento,
¿es necesario?
¿A qué responde la trazabilidad
de requerimientos?
¿Cómo interpreto el
significado de un
requerimiento
determinado?
Entre las decisiones de
diseño, ¿cuáles afectan
la implementación de un
requerimiento
determinado?
¿Están distribuidos todos
los requerimientos?

82. Trazabilidad en la verificación de
los requerimientos
1
¿Es necesario
un elemento de
diseño
determinado?
2
¿Cumple la
implementación
con los
requerimientos?
3
“Are we done
yet?” ¿Ya
llegamos?
4
¿Cuál podría ser
la prueba de
aceptación para
verificar el
cumplimiento
de un
requerimiento?
5
¿Cuál es el
impacto de
modificar un
requerimiento?

83. Gestión de
Requerimientos
• Más allá de documentar los
requerimientos, debemos gestionarlos
• Asegurarnos que son formalizados y
validados
• Definir cuales se incluyen en el
proyecto
• Asociarles información que ayudan a
su gestión (atributos)
• Realizar un seguimiento de los estados
por los que pasan durante el ciclo de
vida del proyecto

84. ¿Para qué sirve la
trazabilidad (Tracking)?
• Cuando la gestión de los
requerimientos es buena, la
trazabilidad puede ser establecida
desde el requerimiento fuente hasta
llegar a sus requerimientos de bajo
nivel, y remontar desde el bajo nivel a
su fuente
• Mantener la trazabilidad bidireccional
entre los requerimientos y los planes y
los productos entregables del
proyecto
• Mantener la trazabilidad bidireccional
de los requerimientos para cada nivel
de descomposición del producto

85. Atributos de los
requerimientos
• Algunos atributos que podemos llevar
asociados a los requerimientos
pueden ser:
• Criticidad o necesidad del
requerimiento
• Riesgo de incorporarlo al
proyecto
• Impacto asociado
• Si es un requerimiento base o
adicional
• Costo de desarrollarlo
• La estabilidad del requerimiento
• La prioridad

86. Atributos de los
requerimientos
• Son información adicional que asociamos a los
requerimientos
• Auxilian a la gestión y desarrollo de los requerimientos
• Pueden enriquecer la información de reportes de
gestión
• De alguna forma también son clasificaciones de los
requerimientos en función de los valores posibles de
cada atributo
• Para negociar entre funcionalidad, planificación,
presupuesto y nivel de calidad, es conveniente que los
requerimientos funcionales tengan asignado un nivel
de necesidad (tres o cuatro categorías: esencial,
deseable, opcional, ...), así como un nivel de prioridad
temporal (dos o tres categorías: alta, baja, ...)

87. Necesidad o criticidad
del requerimiento
• La necesidad de un requerimiento hace
referencia al interés de los usuarios/clientes
en que la aplicación lo realice o cumpla con él
• Por lo tanto se determina en consulta con los
usuarios
• Para definir el nivel de necesidad se pueden
manejar tres o cuatro categorías: esencial o
mandatorio, deseable, opcional, ...
• Si el 20% de la aplicación proporciona el 80%
de su valor... no más del 20% de los
requerimientos deberían ser “esenciales”
• Se puede basar en:
• El nivel de satisfacción del usuario si se
implementan
• El nivel de insatisfacción del usuario si
no se implementan

88. Prioridad de los
requerimientos
• Permite definir en que fase se
implementa cada requerimiento o que
requerimientos quedan fuera
• La prioridad de un requerimiento hace
referencia al orden temporal: indica
en qué fase de construcción del
sistema se incluirá la funcionalidad
que realice el requerimiento
• Se pueden basar en otros atributos
como:
• Criticidad del requerimiento
• Costo de desarrollarlo
• Riesgo de incorporarlo al
proyecto

89. Estabilidad
• Según su estabilidad podemos
identificar:
• Requerimientos estables
• Requerimientos inestables
• Se define la estabilidad de un
requerimiento en función de las
fechas y frecuencia de cambios en el
requerimiento.
• Por ejemplo “el esquema impositivo
cambia todos los años” o “la
legislación de propiedad intelectual
será modificada en 2 años”

90. Otros atributos de
los requerimientos
• Podemos registrar si es un
requerimiento base o adicional (si fue
registrado en la estimación que
definió la propuesta económica al
cliente o si se identificó
posteriormente)
• Podemos registrar el impacto
asociado a cada requerimiento, es
importante sobre todo para
requerimientos adicionales (por
ejemplo: impacto alto, medio, o bajo)

91. Estados de los
requerimientos
Podemos reconocer estados de los
requerimientos para gestionar su
seguimiento, por ejemplo:
• Propuesto
• Incorporado
• En análisis
• En revisión de usuario
• Validado
• No incorporado
• Cancelado
• En desarrollo
• En testeo
• En producción

92. Estados de los
requerimientos
• Es importante registrar
periódicamente en un gráfico la
relación entre:
• Requerimientos formalizados
• Requerimientos modificados
• Requerimientos nuevos
• Si el porcentaje de requerimientos
modificados mas los nuevos no
decrece con el tiempo, existe un
riesgo grave en el proyecto

93. Principales
conclusiones
• La Ingeniería de Requerimientos es primordial
en el proceso productivo ya que se enfoca en
la producción, siendo su tarea la generación
de especificaciones correctas que describan
con claridad, sin ambigüedades y en forma
compacta las necesidades del cliente,
minimizando los problemas relacionados con
la gestión de dichos requerimientos.
• Los requerimientos son importantes debido a
que son la base de todo desarrollo de
software. Obtener requerimientos de calidad
demuestra que el trabajo realizado culminará
con éxito, esto se debe a dos factores:
• La utilización adecuada de las técnicas
de captura de requerimientos con los
clientes.
• La experiencia de los analistas del
proyecto.

94. El Autor
Ingeniero Giovanny Guillén Bustamante
• Ingeniero de sistemas certificado PMP, SCRUM
MASTER, ITIL e IBM i (AS/400).
• Metodologías de desarrollo de software
SCRUM, RUP y SDLC, estimación de proyectos,
aseguramiento de la calidad, integración de
plataformas y gestión de canales electrónicos.
• Experiencia en la gestión de proyectos de
desarrollo de software para el sistema
financiero.