Maestría en Project

Management
Análisis del Negocio
y Requerimientos

UTP Escuela de Postgrado

Diciembre 2023
 Alcance de la Solución

Trazabilidad de los
Requerimentos

Repaso Reuso de los Requerimientos

Paquete de requerimientos

Espacio de conversación
RFI, RFQ, RFP

Comunicar los Requerimientos

 RFI, RFQ, RFP

youtu.be/h5DWiK4BT7M
 Matriz de
Requerimientos
Exposición Grupal
 05
Análisis de los
requerimientos
Análisis de los requerimientos
Describe las tareas y técnicas usadas para analizar los requerimientos declarados por los
stakeholders con el fin de definir las capacidades requeridas por una solución potencial, que
cubra sus necesidades
Priorizar los
requerimientos

Asegura que los esfuerzos del análisis e implementación se

centren en los requerimientos más críticos

Es un proceso de decisión usado para determinar la importancia

relativa de los requerimientos

La importancia puede estar basada en su valor relativo, riesgo,

dificultad de implementación, o en otros criterios.

Requerimientos [priorizados]
Tienen un atributo que describe la importancia relativa para los
stakeholders y la organización, las prioridades se pueden aplicar
a un requerimiento o a un grupo de ellos relacionados
Elementos (aspectos a tener en cuenta)
Bases para la priorización
• Valor de negocio
• Riesgos de negocio o riesgos técnicos
• Dificultad de implementación
• Probabilidad de éxito
• Cumplimiento con reglamentaciones o políticas
• Relación con otros requerimientos
• Acuerdos con los stakeholders
• Urgencia

Retos
• Demandas no negociables: Los stakeholders intentan evitar decisiones difíciles, o no reconocen la
necesidad de llegar a soluciones de compromiso, o desean posicionar todos los requerimientos como de
alta prioridad.
• Soluciones de compromiso poco realistas: El equipo de desarrollo de la solución puede intencionalmente
o no, tratar de influir en el resultado del proceso de priorización, sobrestimando la complejidad o
dificultad de implementación de ciertos requerimientos
Bases para la priorización
• Prioriza según el análisis de costo-beneficio de su valor relativo para la organización
Valor de negocio
• Los requerimientos más valiosos serán objeto de desarrollo en primer lugar

• Selecciona los requerimientos que presentan el riesgo más alto de falla del proyecto
Riesgos de negocio o técnicos
• Son investigados e implementados primero para asegurar el menor gasto posible.

• Selecciona los requerimientos que son más fáciles de implementar

Dificultad de implementación
• A menudo usado durante el piloto de un proceso de desarrollo o herramientas nuevas

• Se centra en los que probablemente produzcan ciertos resultados rápidamente

Probabilidad de éxito
• Cuando un proyecto es controvertido y el progreso es necesario para obtener apoyo

Cumplimiento con • Prioriza los requerimientos que deben ser implementados con el fin de cumplir con
reglamentaciones o políticas las demandas regulatorias o políticas impuestas

Relación con otros • Un requerimiento puede que no sea de gran valor, pero puede apoyar otras
requerimientos necesidades de alta prioridad y ser un candidato para su pronta implementación

Acuerdos con los • Requiere que los stakeholders alcancen un consenso sobre cuáles requerimientos son
stakeholders más útiles o de más valor

Urgencia • Prioriza los requerimientos de acuerdo a las limitaciones de tiempo

Priorización de Proyectos
Preguntas a tener en cuenta a la hora de valorar cada idea

Propósito ¿Cuál es el propósito de la organización?

Prioridades ¿Cuáles son los retos más relevantes?

Proyectos ¿Qué proyectos pueden acercar estos objetivos?

Personas ¿Quiénes deben encargarse del proyecto?

Performance ¿Cómo se medirá el grado de éxito de la idea?

Jerarquía del Propósito
Herramienta que ayuda a priorizar ideas con impacto
Reflexión sobre la visión y misión de la compañía, es decir, concretar qué metas espera conseguir la empresa, pues
este propósito será la base de la actuación futura de la empresa.
Propósito ¿Cuál es el propósito de la organización y cómo se lo persigue?
¿Cuál es la visión estratégica que apoya este propósito?

Dado el propósito y la visión establecidos,

Prioridades ¿Qué es lo más importante para la empresa ahora y en el futuro?
¿Cuáles son sus prioridades ahora y en los próximos dos a cinco años?

Determinar las iniciativas que pueden convertir en realidad las metas empresariales, según los recursos
disponibles, desechando las que por falta de presupuesto, relevancia o alineación, no cumplan con estos requisitos
Proyectos ¿Qué proyectos son los más estratégicos y deberían ser financiados al máximo?
¿Qué proyectos se alinean con el propósito, la visión y las prioridades, y cuáles deben detenerse o desecharse?

Ahora que hay claridad en torno a las prioridades estratégicas y los proyectos que más importan, los directivos
Personas deben identificar y organizar a los profesionales de la empresa más adecuados para implementar las iniciativas
¿quiénes son las mejores personas para ejecutar esos proyectos?

Valorar aspectos relativos al alcance, costo, tiempo empleado, beneficio o consecución de objetivos
¿Cuáles son los objetivos relacionados con los resultados que medirán el desempeño real y la creación de valor?
Performance Aquí, una compañía puede basarse en los indicadores de desempeño vinculados a los insumos (por ejemplo,
alcance, costo y tiempo) o a los productos (como los beneficios, el impacto y los objetivos).
Organizar los requerimientos
Crear un conjunto de vistas de los requerimientos para la
solución de negocio, que sean exhaustivas, completas,
congruentes y entendidas desde todas las perspectivas de los
stakeholders

Entender cuales modelos son apropiados para el dominio del

negocio y el alcance de la solución

Identificar el modelo de interrelaciones y dependencias

Estructura de los requerimientos

se utiliza de modo que se conozca donde debería encontrarse un
requerimiento especifico, cada modelo o conjunto de
requerimientos debe tener un alcance claro implícito
Pautas a seguir

Uso simple, definiciones

Seguir estándares de la
organización que describen
los tipos de requerimientos debe seleccionar un conjunto
que serán usados en los
proyectos
congruentes para cada tipo de
Si no existen estándares, se
requerimiento descritos en un
lenguaje natural, y usando la
de técnicas apropiadas
terminología de negocio que
prevalece en la empresa

Producir un conjunto
Documentar las dependencias
congruente de modelos y
e interrelaciones entre los
plantillas para documentar los
requerimientos
requerimientos
Modelado (conceptos generales)
•Los modelos clasifican y describen a las personas que interactúan directamente con una solución
Clases, perfiles o •Cada rol agrupa personas con necesidades, expectativas y metas similares
roles de usuarios •Cada rol puede corresponder a un stakeholder y deben ser investigados como fuente de requerimientos

•Los conceptos corresponden a algo en el mundo real; un lugar, una persona, una cosa, una organización
Conceptos y
•Definen los objetos, entidades o hechos que son relevantes para el dominio de negocio y que relaciones
relaciones tienen con otros conceptos

•Una solicitud a un sistema de negocio u organización para hacer algo, tal como que un cliente haga un
Eventos pedido, o un administrador solicite un reporte, puede ser descrito como un evento
•Pueden provenir de fuera del negocio, desde dentro o puede ocurrir en un tiempo programado

•Son una secuencia de actividades repetibles ejecutados dentro de una organización

Procesos •Los procesos describen quien, y en que ha de participar para responder por completo a un evento, o
como las personas en la empresa cooperan para lograr una meta

•Son utilizadas por la empresa para imponer metas y guiar la toma de decisiones
Reglas •Determinan cuando la información asociada con una entidad puede cambiar, cuales valores de la
información son válidos, como se toman las decisiones en un proceso, y cuáles son las prioridades
Especificar y modelar los
requerimientos
Analizar los deseos expresados por los stakeholders
y/o el estado actual de la organización utilizando
una combinación de declaraciones textuales,
matrices, diagramas y modelos formales

Las especificaciones y modelos son creados para

analizar el funcionamiento de una organización y
brindar una comprensión de oportunidades de
mejora

Requerimientos [analizados]
modelados y especificados
Elementos (aspectos a tener en cuenta)
• Describir las capacidades de la solución, cualquier condición que debe existir para que el
Texto requerimiento opere y cualquier limitación que pueda impedir que la solución satisfaga el
requerimiento

• Una tabla es la forma más simple de una matriz

Matriz de • Puede descomponerse en elementos que se aplican a cada entrada en la tabla
Documentación • Los atributos y los diccionarios de datos se expresan a menudo en forma tabular

• Cualquier representación simplificada de una realidad compleja

• Es útil para comprender esa realidad y tomar decisiones relativas a ella
Modelos • Pueden ser de texto o gráficos, o alguna combinación de ambos
• Los modelos gráficos se refieren a menudo como diagramas

Captura de • En la medida que cada requerimiento o conjunto de requerimientos es especificado y

atributos modelado, deben ser capturados los atributos relevantes

Oportunidades de • Siempre se debe trabajar en identificar oportunidades de mejorar la operación del

Mejora negocio
Pautas para redactar los requerimientos

No presuponer que el
Expresar uno y solo Evitar cláusulas
lector tiene Usar terminología
un requerimiento a la condicionales
conocimiento del congruente
vez complejas
dominio

Describir claramente Usar terminología

Expresar
quién o qué es familiar a los
requerimientos con
responsable por stakeholders que
un verbo o una frase
satisfacer el deben revisar o usar
verbal
requerimiento el requerimiento
Oportunidades de Mejora
Automatizar o
Tareas relativamente simples, donde las decisiones se toman basándose en reglas estrictas o inflexibles, son
simplificar el trabajo las principales candidatas para la automatización
de las personas

Proporcionar mayor información al personal que tenga una relación directa o indirecta con los clientes
Mejorar el acceso a
la información Los responsables de la toma de decisiones puede que exijan este nivel de detalle, pero deberían tener
conocimiento de donde y de quien se puede obtener si es necesario

Reducir la Las interfaces son necesarias siempre que se transfiere trabajo entre los sistemas o entre las personas
complejidad de las
interfaces La reducción de su complejidad puede mejorar el entendimiento.

Incrementar la
Diferentes trabajadores pueden administrar casos similares de una manera muy diferente, causando la
congruencia en el insatisfacción y la frustración del cliente
comportamiento

Eliminar la Los diferentes grupos de stakeholders pueden tener necesidades comunes que se pueden resolver con una
redundancia sola solución, reduciendo el costo de la implementación
Diseñando procesos fáciles de adoptar
Mejorar el valor
aportado (punto de vista
del cliente/usuario)

Beneficios comprensibles
Aprovechar estándares y
y comunicables para
externalidades
todos los afectados

Minimizar la resistencia
Resultados observables y
ANTES de lanzar el nuevo
medibles (KPI)
proceso

Siempre es preferible
«pilotear» antes que
hacer un «big-bang»
 Matriz de Requerimientos (ejemplo)
Nombre del proyecto
Descripción del proyecto
Necesidad del negocio
Descripción del Objetivos del
ID Grupo ID de requerimiento Oportunidades Metas EDT entregables Casos de prueba
requerimiento proyecto
Requi s i to s ol i ci tado por El objetivo es el pa s o
l os s takehol ders . que s e qui ere cumpl i r
Des cri pci ón de que pa ra poder a l ca nza r l a Li s tado de l a s
comprende o en qué Toda ci rcuns tanci a en l a meta. es tra tegi a s y es cena ri os
Cl a s i fi ca ci ón Stakehol ders : Pers ona s o cons i s te el requi s i to. La cua l exi s te l a pos i bi l i da d Víncul o del requi s i to con de prueba s que s e
de l a grupos que s e i mpa ctan des cri pci ón depende del de l ogra r a l gún tipo de La meta es el fi n úl timo l os objetivos del Compromi s o o contempl a rá n pa ra
neces i da d por o s e s i enten i mpa ctada s tipo, por ejempl o mejora de índol e a l que s e qui ere l l ega r proyecto. Aquí s e Entrega bl es va l i da r l a a ceptaci ón del
grupos por el proyecto requi s i tos del negoci o, económi ca , s oci a l , es tabl ece l a tra za bi l i da d requi s i to. Es tos s e
de l os i nteres a dos , l a bora l , etc. entre el requi s i to y l os defi nen a pa rtir de l os
funci ona l es , no objetivos es pecífi cos del cri teri os de a ceptaci ón
funci ona l es , del proyecto proyecto defi ni dos e s u
o del producto a l ca nce.
1.0
1. 1.1
1.2
2.0
2. 2.1
2.2
3.0
3. 3.1
3.2
4.0
4. 4.1
4.2
Matriz de Requerimientos (1/4)
• Debe ser único
Identificador • Definir un estándar para numerar cada requisito e identificarlo unívocamente
• Puede definirse una numeración (por ejemplo 001, 002, 003).

• Vinculación de requisitos de alto nivel con requisitos más detallados

Vinculación • Definir numeraciones separadas por punto para asociar requerimientos específicos con un
requerimiento general (por ejemplo 1.1, 1.2 y 1.3 para requisitos asociados al requerimiento 001).

• Narrativa que describe en que consiste el requerimiento de proyecto

• Tener en cuenta el tipo de requerimiento de proyecto que se esté documentando
Descripción • Del negocio / De los interesados / Del proyecto / De calidad
• De la solución: pueden ser funcionales o no funcionales

• Los requerimientos se pueden ir modificando o agregando información en versiones sucesivas,

Versión por lo que es conveniente llevar el control por número de versión
Matriz de Requerimientos (2/4)
• Activo / Cancelado
Estado • Diferido / Agregado
• Aprobado / Asignado / Completado

• Es la fecha en la que se estableció el último cambio de estado del requerimiento

Fecha de
• Por ejemplo, si el requerimiento cambio de estado aprobado a estado asignado el 01-07-2018, el
Estado estado actual es “asignado” y la fecha de estado es 01-07-2018

Propietario • Persona responsable de velar por que se logren los resultados con el requerimiento

• Se toma en cuenta el grado de importancia del requerimiento para el logro de objetivos del
proyecto y realización de sus beneficios, para asignar un nivel de prioridad
Prioridad • También puede tenerse en cuenta el grado de influencia del stakeholder solicitante según
determine la gestión de los interesados del proyecto
Matriz de Requerimientos (3/4)
• Criterios de estabilidad, complejidad y aceptación. Es importante que los criterios sean
específicos, medibles de forma objetiva y respondan a un estándar organizacional
Criterios • La complejidad puede establecerse de forma cualitativa, por ejemplo, baja, moderada o alta
• Los criterios de aceptación son una lista de condiciones específicas que debe cumplir el
requerimiento para poder pasar a estado “completado”

• Definición de necesidades, oportunidades, metas y objetivos de negocio

• Son los elementos de planificación estratégica que dieron origen al requerimiento
Oportunidades • Todo requerimiento debe estar alineado con beneficios que la organización espera obtener
y Objetivos • Estos beneficios responden a nuevas oportunidades, objetivos y metas de crecimiento, o
necesidades emergentes específicas. Por ejemplo, aspectos regulatorios o necesidades
obligatorias para responder a amenazas de competidores

• Establece la trazabilidad entre el requisito y los objetivos del proyecto definidos en su alcance
Objetivos del
• Los objetivos de proyecto a su vez deben estar asociados a necesidades, oportunidades, metas u
Proyecto objetivos de negocio
Matriz de Requerimientos (4/4)
• Alcance del proyecto y entregables de la estructura de desglose de trabajo (EDT)
Entregable • Entregables de la estructura de desglose de trabajo (EDT) en los cuales está inmerso el requisito
(EDT) • Puede especificarse tanto el nombre del elemento de la EDT como su código EDT

Diseño del • Si el requerimiento tiene implicaciones de cómo debe diseñarse el producto, aquí se explican
producto cómo se incorporarán los compontes necesarios al diseño para satisfacerlo

• Describe como los procedimientos de trabajo, metodología o estándares incorporan el requisito

Desarrollo del
• Esto aplica para requisitos que definen la forma de trabajar y estándares a cumplir, como por
Producto ejemplo requerimientos de proyecto o de calidad.

• Partiendo de los criterios de aceptación que debe cumplir el requerimiento, se establecen

Casos de estrategias y escenarios de prueba específicos, según el sector industrial o área técnica en la que
se desenvuelve el proyecto
Prueba
• Esta información servirá de insumo para planificar el control de calidad del proyecto.
Definir los supuestos y las limitaciones

Identificar factores, además de los requerimientos, que pueden afectar

cuáles soluciones son factibles

Los supuestos son factores que se cree que son ciertos, pero no han sido
confirmados, pueden afectar todos los aspectos del proyecto y presentar
un cierto grado de riesgo si no demuestran su veracidad

Las limitaciones se definen como las restricciones

o impedimentos en las posibles soluciones

Supuestos y limitaciones:
reducirán las opciones potenciales de solución
y serán monitorizadas por cambios potenciales
Elementos (aspectos a tener en cuenta)
• Un supuesto es algo que se cree que es cierto, pero que en realidad no ha sido verificado
• Pueden referirse a algo en el presente o en el futuro
Supuestos • Deben ser documentados, y si se encuentra que un supuesto es falso, esto por lo general
afectará al proyecto de alguna manera
• Son por lo tanto una fuente de riesgo potencial del proyecto

• Describen las limitaciones en las soluciones disponibles o en un aspecto de la situación

Limitaciones de actual que no puede ser cambiado por el despliegue de la solución nueva
• Pueden reflejar limitaciones presupuestarias, de tiempo, en la cantidad de recursos
negocio disponibles, en las habilidades del equipo del proyecto, un requerimiento de que ciertos
stakeholders no sean afectados por la implementación de la solución

• Incluyen cualquier decisión técnica que se tome y pueda afectar el diseño de la solución
• Pueden incluir lenguajes de desarrollo, plataformas de hardware y software, y aplicación
Limitaciones de software que deban utilizarse.
técnicas • También pueden describir limitaciones como la utilización de recursos, el tamaño y
oportunidad del mensaje, tamaño de la aplicación de software, tamaño y cantidad
máximos de archivos, registros y elementos de datos
Supuestos / Paradigmas
Es importante explicitar los supuestos que
estamos haciendo, a fin de recibir si son
razonables o no
Es imposible prescindir de supuestos, pero hay
que tener cuidado de tenerlos implícitos en
nuestra mente

Nos permite aprender y evitar errores,

enriquece el proceso
Verificar los requerimientos
Garantiza que las especificaciones y modelos de los requerimientos
cumplan con el estándar de calidad necesario para permitir que se utilicen
eficazmente

Los requerimientos que no cumplen con los estándares de calidad son

deficientes y deben ser revisados

Que proporcionen toda la información necesaria para seguir trabajando

basándose en los requerimientos a ser realizados

Requerimientos [verificados]
Son de calidad suficiente como para permitir un trabajo adicional a ser
realizado basado en aquellos requerimientos
 Características de Calidad

Cohesivo Completo Congruente Correcto Factible Modificable Inequívoco Verificable

Actividades de Verificación

Comparar cada modelo de

Asegurar que todas las
requerimientos (textual o
Verificar que cada modelo de variaciones de los procesos
grafico) en relación con todos
requerimientos esté completo documentados se han
los otros modelos de
identificado y documentado
requerimientos preparados

Asegurar que la terminología

Asegurar que se han tomado en
utilizada para expresar el Añadir ejemplos cuando sea
cuenta todos los activadores y
requerimiento es comprensible apropiado para aclarar y
resultados en todas las
y congruente con el uso dentro fortalecer el caso de negocio
variaciones
de la organización
Validar los requerimientos
Asegurar que todos los requerimientos apoyen la entrega de valor a la empresa,
cumplan con sus metas y objetivos y respondan a la necesidad de los stakeholders

Es un proceso continuo para asegurar que los requerimientos de los stakeholders y

de la solución se alinean con los requerimientos del negocio

La implementación de los requerimientos como un todo debe ser suficiente para

lograr ese estado futuro deseado para los clientes y usuarios

Requerimientos [validados]
aquellos que pueden demostrar que ofrecen valor a los stakeholders y están
alineados con las metas y objetivos de negocio, si no puede ser validado, no
beneficia a la organización o no entra dentro del alcance de la solución
Elementos (aspectos a tener en cuenta)

Identificar supuestos

Determinar las dependencias para la realización de beneficios

Determinar el valor del negocio

Evaluar la alineación con el caso de negocio y el costo de

oportunidad
Business Case
Es la herramienta que permite a las organizaciones justificar la inversión en un proyecto o algún cambio

Permite a la organización (al nivel de dirección o gobernanza) tomar las decisiones más importantes en
relación al proyecto: autorizar su inicio, parar el proyecto, confirmar el cierre, etc.

Un proyecto, para pasar de candidato a ser iniciado por parte de la organización, debe ser:

• deseable (presenta una buena relación costo beneficio)

• viable (los costos son asumibles)
• alcanzable (disponemos de las capacidades para poder llevar a cabo el trabajo)

Permite evaluar si el proyecto lo es y lo seguirá siendo a lo largo del proyecto

Sirve como herramienta de comunicación con los principales stakeholders

Importancia del Business Case
Ayudan a las organizaciones a comprender las opciones de proyectos y lo
que cada una costará en términos de tiempo, dinero y oportunidades
perdidas o ganadas

Muestran a los encargados de tomar decisiones que hay rigor detrás de

ciertos cursos de acción

Muestran que las decisiones se basan en investigaciones y hechos, en

oposición a la opinión de una persona

Ayudan a las empresas a justificar sus gastos, así como ayudar a proteger a
los clientes potenciales del proyecto si algo sale mal
Componentes del Business Case
Beneficios
•Valor que el negocio espera obtener con el resultado del proyecto. En el futuro debe poder evaluar si los beneficios previstos se han cumplido
•Pueden ser monetarios (mayores ingresos) o cualitativos (mejora en eficiencia, en calidad), pero deben poder ser siempre medibles
Costos
•Indicar los costos totales, no sólo los del proyecto, sino también los asociados a las operaciones, administración y mantenimiento
•Si evaluamos beneficios a cinco años, deberemos considerar también los costes a cinco años
Riesgos
•El proyecto puede ser deseable, pero contener riesgos importantes que pongan en duda su viabilidad
•Debe siempre hacerse referencia a aquellos riesgos relativos al cambio global para que la organización pueda decidir si los puede asumir o no
Cronograma (hitos principales)

•Los hitos temporales más relevantes en cuanto a la obtención de los beneficios y el consumo de costos

Opciones de negocio
•Debería poderse evaluar la propuesta de proyecto respecto a la opción de no hacerlo (menos costos, pero también menos beneficios)
•Considerar cualquier opción que permita a la organización satisfacer su necesidad, establecer beneficios y costos de cada alternativa
Evaluación de la inversión

•Se pueden utilizar para este análisis diferentes técnicas como el ROI (retorno de la inversión), payback period, net present value y otros
 Algunas preguntas para iniciar

¿Qué y para qué? ¿Por qué? ¿Cómo? ¿Cuándo?

• El inicio de este viaje lo • Es preciso reflexionar
marcan la definición del
proyecto y de sus metas
• Es importante
especificar el alcance
• Hace falta ver cómo • El riesgo es inherente a
sobre los supuestos que avanzar y tener clara la cualquier iniciativa , por
inspiran la iniciativa y manera de medir el eso, hay que averiguar
los problemas que se progreso cuál es el que amenaza
desean resolver • Un buen business case al proyecto y cómo
necesita incluir superarlo o mitigarlo
ejemplos de los
indicadores a evaluar
• No pueden faltar
métricas que faciliten
conocer el ROI o el valor
actual neto, entre otras
 Pasos para un Business Case

Calcular la fecha
Planear una
Mencionar los Evaluar las Estimar riesgos y estimada de la
Detallar el estrategia para Definir bien el
precedentes y/o métricas: VAN, crear una implementación
proyecto y sus presentar y alcance del
problemas a TIR, TCO, flujo estrategia para del proyecto y
objetivos comunicar proyecto
solucionar de caja y ROI disminuirlos principales
el proyecto
actividades
Business Case
(Plantilla)
 Business Case
Caso de Negocio
Tiempo Grupal
Tarea Semana 5

Revisar su matriz de requerimientos en base a la plantilla recomendada, podrá colocar

campos adicionales o información adicional de sustento

Elaborar el business case de su proyecto de inversión o cambio para la empresa que el grupo
ha escogido

Utilizar la plantilla de ejemplo, se pueden colocar elementos adicionales en la medida que los
consideren necesarios para brindar mejor información para la toma de decisiones
GRACIAS!