Este documento describe los pasos para el desarrollo de requerimientos, incluyendo la preparación del escenario, declaración de la visión, definición del problema, creación de un glosario y la identificación de riesgos en los requerimientos. Explica cómo desarrollar una declaración de visión concisa que define el propósito del producto, y cómo documentar la definición del problema y los riesgos de los requerimientos usando plantillas. El objetivo es establecer un conocimiento compartido para guiar el desarrollo de requerimientos.
2. Preparar el escenario
• Desarrollar actividades para establecer un
conocimiento compartido del producto a
desarrollar.
2
Cuando necesite Entonces crear
Definir la visión del producto Visionamiento
Aclarar términos Glosario
Identificar los riesgos de los
requerimientos
Una estrategia para mitigar los
riesgos en los requerimientos
3. Declaración de la visión
• Declaración concisa que define: el Qué, Porqué y
Quien del producto final.
• Se utiliza en otros documentos como es, en el
documento de iniciación del proyecto y en el
documento de visión del producto.
• Permiten establecer casos del negocio, objetivos
generales del negocio y otra información de cómo
el proyecto debe operar.
3
4. Declaración de la visión
• Preguntas clave:
– el producto?
– hará el producto para sus stakeholders?
– Cuales son las razones para comprar o utilizar este
producto?
–
disponible?
– Como se distinguirá en el mercado?
4
5. Declaración de la visión
1. Determinar/definir lo siguiente:
– Cliente objetivo (Target Customers).
– Necesidad u oportunidad.
– Nombre del producto.
– Categoría del producto.
– Principales beneficios y razones para utilizar.
– Alternativa competitiva primaria, sistemas
actuales o proceso manual actual.
– Diferencias primaria del producto.
5
6. Declaración de la visión
2. Documentar el visionamiento con las definiciones
realizadas en una plantilla.
6
Para <Cliente Objetivo> quien <Necesidad u
oportunidad>, el <nombre del producto> es un
<categoría del producto> que <Principales
beneficios y razones para utilizar>
A diferencia de <primera alternativa competitiva,
sistemas o procesos actuales>, nuestro
producto <Diferencias primaria del producto>.
7. Declaración de la visión
3. Revisar el visionamiento y validar que este
alineado con las metas y los objetivos del
negocio.
• Contar con un sponsor para asegurarse que la visión
se ajusta con los objetivos organizacionales y
departamentales.
• Contar con un equipo de trabajo, idealmente en
colaboración con el sponsor del proyecto, con la
finalidad de revisar el visionamiento como sea
necesario.
7
8. Declaración de la visión
Ejemplo:
Para las compañías de servicio y su staff quienes proveen
servicios de limpieza de ventanas a casas y locales comerciales,
el sistema CVGC es un aplicación Web que estima el
cronograma de trabajo, asigna personal a los trabajos, y
promociona los servicios de la compañía. A diferencia de los
productos existentes que no permiten a múltiples compañías
colaborar en ofertas y optimizar la asignación de personal,
nuestro producto l9ples compañías el uso de la
aplicación, provee ciclo vida completo del negocio para todas
sus operaciones (incluye cuentas por pagar y cuentas por
cobrar), y es fácil de usar.
8
9. Definición del problema
• Declaración del problema:
• Describe le problema actual que el negocio esta
experimentando y clarifica cuál sería una solución
exitosa.
• Es útil cuando la solución involucra la mejora del
producto existente o cuando la implementación
del producto crea una necesidad de cambios en
los procesos de negocio.
• Puede ser útil para definir la visión del producto.
9
10. Definición del problema
• Para documentar se utiliza la siguiente plantilla:
10
El problema de <insertar la declaración del
problema> afecta <nombre de las personas
afectadas, organizaciones o grupos de
usuarios>. El impacto de esto es <nombre del
impacto (decisiones pobres, exceso de costos,
información o procesos erróneos, 9empos de
respuesta los clientes, etc.)> Una solución
exitosa sería <describa la solución>.
11. Definición del problema
• Ejemplo:
El problema de cotización y planificación de trabajos y paga a
contratistas utilizando los procesos manuales y automáticos
actuales afecta a clientes, contratistas, planificadores y
contadores. El impacto de esto son estimaciones inexactas,
reservas duplicadas, espacios vacíos en la planificación de trabajos
y sobrepagos o pagos insuficientes de los contratistas. Una
solución exitosa sería permitir respuestas inmediatas a las
peticiones de cita con los contratistas, proveer la habilidad de
planificar y completar los trabajos dentro de la semana que se han
requerido, permitir la facturación de los clientes del sistema, y
emitir los pagos semanales a los contratistas
11
12. Glosario
• Diccionario de términos comunes y relevantes
para el producto que va ha ser construido,
mejorado o adquirido.
• Se deberá utilizar los términos del glosario
durante la captura, documentación de
requerimientos y a lo largo de la vida del
proyecto.
12
13. Glosario
• Ejemplo
13
Término Definición Alias Ejemplo
Trabajo Conjunto de servicios
provistos a un cliente
en una hora y
dirección especifica.
Orden de trabajo Limpiar 25
ventanas, 3
espejos internos y
1 claraboya en la
calle 49
Contratista Unidad de negocio
(usualmente una o
más personas)
realizando el trabajo.
Sub-contra9sta
Trabajador
Jeff Rhodes
Jhon Glen
Lugar Localización física con
una o mas direcciones
asociadas a un cliente.
Lugar de Trabajo
Localización del
trabajo
Marcelino
Chanpagnat
Campus UTPL,
Loja.
14. Riesgos en los requerimientos
• Los riesgos son sucesos o condiciones que podrían
poner en peligro el proyecto.
• Los riesgos deben ser evaluados, rastreados y
controlados a lo largo del proyecto.
• Es necesario identificarlos para:
– Ayudar al equipo a prevenir obstáculos.
– Establecer acciones para evitar o minimizar los riesgos.
– Permitir al equipo comunicar honestamente acerca de los
potenciales obstáculos
14
15. Riesgos en los requerimientos
• Se debe establecer una estrategia para mitigar los
requerimientos de acuerdo a lo siguiente:
1. Reunir a los stakeholders para revisar y adaptar una
lista de potenciales riesgos de requerimientos.
2. Clasificar los riesgos.
3. Representar gráficamente las clasificaciones y
ponerse de acuerdo en los riesgos que se abordarán.
4. Determinar las formas de controlar, evitar o mitigar
los posibles riesgos críticos.
15
16. Riesgos en los requerimientos
Riesgos comunes en los
requerimientos
Estrategias de mitigación
Falta de participación del usuario • Identificar a los interesados del
producto.
• Crear un plan de participación de
interesados.
• Usar técnicas de captura que atraigan
a los usuarios en el proceso
Expectativas poco realistas de los
clientes.
• Crear la visión del producto.
• Desarrollar modelos de alcance del
proyecto
• Validar requerimientos con prototipos
operacionales.
16