PRACTICAS AGILES

Necesidades del Cliente y

Requerimientos de Software

Por: Carolina Sandoval

 Introducción a los requerimientos
En el curso de introducción, se indico que hacer un mejor software
implica tres objetivos.
The right
product • the right product (el producto correcto)
• done right (bien hecho)
• managed right (bien gestionado)

Done right
El producto correcto significa satisfacer las necesidades de sus
clientes y usuarios finales y no sólo a sus necesidades. Esto implica
la comprensión el problema que se tiene que resolver y las tareas
Managed que necesitan cumplir con el software.
right
Para lograr el producto bien hecho y bien gestionado, el software
desarrollo debe comenzar con un conjunto calidad de
requerimientos del software, que serán más adelante planeado,
diseñado, implementado, y probado.
 Introducción a los requerimientos
¿Qué es un requerimiento?
Uno de los aspectos más críticos de la Gestión de Producto de Software es lidiar con
condiciones conocidas como requerimientos.

Muchas definiciones se han desarrollado para describir “requerimientos". Un

requerimiento se entiende más fácilmente como una descripción específica de las
necesidades de su cliente, que puede ser utilizado para ayudar a crear un producto en el
mundo real.

Requerimientos bien definidos ayudan a hacer

las necesidades del cliente estén comprendidas
y bien abordadas , también ayudan a detectar
problemas potenciales antes de que se
conviertan en grandes y costosos de arreglar.
 Introducción a los requerimientos
Actividades de Requerimientos
Proceso En el tema anterior, Proceso Software y Prácticas Agiles, el
desarrollo de software es un proceso organizado, con una serie de
Fases fases, agrupados dentro de cada fase es una serie de uno o más
actividades conjuntos de tareas relacionadas.
Actividades
Los requerimientos son establecidos a través de actividades en el
Tareas comienzo de un proyecto. Ello determina el propósito de un producto
y cómo el producto puede cumplir con ese propósito.

Con las actividades correctas, los requerimientos adecuados pueden ser establecidos,
escritos en la forma apropiada, e incluso mejorada.
Exploraremos cinco actividades requerimientos importantes:

1. Obtención de 2. Expresión de 3. Priorización de 4. Analisis de 5. Gestión de

Requerimientos Requerimientos Requerimientos Requerimientos Requerimientos
Introducción a los requerimientos
Actividades de Requerimientos

2. Expresión de 3. Priorización de 4. Analisis de 5. Gestión de

1. Obtención de Requerimientos
Requerimientos Requerimientos Requerimientos Requerimientos
 Introducción a los requerimientos
Actividades de Requerimientos

2. Expresión de 3. Priorización de 4. Analisis de 5. Gestión de

1. Obtención de Requerimientos
Requerimientos Requerimientos Requerimientos Requerimientos

La actividad de la obtención de
requerimientos es un proceso
interactivo y de investigación,
que se produce en reunión con el
cliente y usuarios.

“Quieren “ Vs. “Necesitan”

Un "querer" es por lo general una funcionalidad o característica que el cliente le gustaría que el
producto posea, lo que puede aportar un valor añadido, pero no es necesariamente núcleo al
producto en sí. Una “necesidad", por el otro lado, es una funcionalidad básica que el producto debe
tener en para cumplir con el propósito del producto.
Necesidades deben tomar prioridad en el desarrollo de productos.
 Introducción a los requerimientos
Actividades de Requerimientos

2. Expresión de 3. Priorización de 4. Analisis de 5. Gestión de

1. Obtención de Requerimientos
Requerimientos Requerimientos Requerimientos Requerimientos

La actividad de la obtención de
requerimientos es un proceso
interactivo y de investigación,
que se produce en reunión con el
cliente y usuarios.

Papel del Gerente de Producto de Software

Es el papel de la gerente de producto de software para ayudar al cliente a discernir lo que
"quiere" y lo que "necesita“, asegurarse de que metas son factibles, las expectativas del
cliente son realistas, y la producto producido es el mejor resultado posible.
La mejor manera de descubrir y desarrollar "necesidades" y "deseos" con su cliente es a
través de la obtención de requerimientos donde usted participar en la discusión sobre el
producto con su cliente..
 Introducción a los requerimientos
Actividades de Requerimientos

2. Expresión de 3. Priorización de 4. Analisis de 5. Gestión de

1. Obtención de Requerimientos
Requerimientos Requerimientos Requerimientos Requerimientos

La actividad de la obtención de
requerimientos es un proceso
interactivo y de investigación,
que se produce en reunión con el
cliente y usuarios.

Obtención Vs. Recopilación

Obtención de Requerimientos no deben confundirse con "Recopilación de requerimientos ."
“Recopilación de Requerimientos" es el enfoque más pasivo de simplemente preguntar al cliente lo
que le gustaría hacer, y que a menudo pone el equipo de desarrollo en un proceso reactivo.
Obteniendo requerimientos, sin embargo, se involucra en un debate a profundidad y la colaboración
desde el inicio del producto desarrollo, por lo tanto el cliente y el equipo de desarrollo trabajan juntos
para construir un producto de éxito.
 Introducción a los requerimientos
Actividades de Requerimientos
2. Expresión de Requerimientos
A menudo, los requerimientos se
describen primero a través de
notas de encuentros con los
clientes.
Es mejor y más concreto usar
representaciones para expresar
los requerimientos
Casos de uso
Historias de usuario
Storyboards
3. Priorización de Requerimientos
Una vez la visión de lo que hay
que hacer para el proyecto se ha
establecido a través de la
obtención y expresión de
requerimientos, es importante
dar prioridad a las necesidades
del cliente, especialmente en la
metodología Scrum. Preguntas
para ayudar a establecer
prioridades incluyen:
¿Qué requerimientos DEBEN
realizarse para que el proyecto y
producto tenga éxito?
¿Qué requerimientos DEBERIAN
hacerse? En otras palabras, lo que
es importante, pero no es tan
crítico podría ser satisfecho otra
manera o en un momento
posterior en el proyecto?
¿Qué requerimientos se
PODRIAN hacer para mejorar el
proyecto o producto pero no es
necesario?
4. Analisis de Requerimientos
El proceso de examinar el listado
de requerimientos de un
proyecto para asegurarse de que
son claros, completos y
coherentes es conocido como el
análisis de requerimientos.
Un proyecto debe ser
continuamente evaluado y los
requerimientos mejorado.
Ayuda a resolver requerimientos
conflictivos o identificar
problemas entre requerimientos
Asegura que los requerimientos
identificados reflejan y se
relacionan con el producto que se
está construyendo
5. Gestión de Requerimientos
Se trata de la organización y re-
organización de requerimientos
y, posiblemente, la reutilización
de los subconjuntos de los
requerimientos en diferentes
etapas.
Proceso continuo
Seguimiento de las prioridades,
análisis, y cambios en los
requerimientos .
Todo esta conectado, si algo
cambia en un requerimiento
afectará a otros y el desarrollo del
producto.
 Introducción a los requerimientos
Actividades de Requerimientos
Sobre la base de la comprensión de los requerimientos asociado a las actividades, se
considerará los siguientes tipos de requerimientos :

1. Requerimientos del negocio

Influir en el producto
2. Reglas del negocio
3. Requerimientos de usuario
4. Requerimientos funcionales Requerimientos básicos
5. Requerimientos no funcionales
6. Interfaces externas
7. Configuración de productos físicos Contexto para el diseño e implementación
8. Limitaciones de desarrollo
Los requerimientos del negocio y reglas de negocio pueden influir en el proyecto,
mientras que las necesidades del usuario, requerimientos funcionales y requerimientos
no funcionales se consideran requerimientos básicos.
Por último, las interfaces externas, configuración de productos físicos, y limitaciones
para el desarrollo son los requerimientos que suman contexto para diseño e
implementación del producto.
 Tipos de Requerimientos
Requerimientos del Negocio
Hay muchas definiciones posibles para los requerimientos
del negocio.
En este curso, los requerimientos del negocio se refieren a
aquellos requerimientos que implican el propósito del
proyecto.
En los requerimientos del negocio, los objetivos se
presentan en términos concretos y específicos. Estos
objetivos suelen ser valores empresariales tangibles o
cuantificables que pueden ser utilizados por los analistas de
negocio.

Un ejemplo de un requisito de negocio podría ser: "El cliente

hay que reducir los errores en los pedidos realizados a su
empresa en un 25% a finales del próximo año para
aumentar sus ingresos anuales por $us. 10.000 ".
 Tipos de Requerimientos
Reglas del Negocio
Los requerimientos del negocio no deben confundirse con las normas de la empresa, a
pesar de que a menudo se asocian. Requerimientos del negocio ocupan de “por qué se
persigue el proyecto”, mientras que reglas de negocio son las “limitaciones sobre cómo
funciona el producto”.

Las reglas de negocio son a veces necesarias realizar para un proyecto apropiado o
exitoso. A menudo son los presupuestos, políticas, lineamientos o reglamentos.

Ejemplos de reglas de negocio son: • Requerimientos de

uniformidad de la marca
• Gubernamentales o • Políticas de privacidad
jurídicas normativas
 Tipos de Requerimientos
Requerimientos de usuario

Los usuarios o usuarios finales son las personas que van

a utilizar el software una vez que haya sido creado.

Requerimientos de usuario, son las tareas que estos

usuarios pueden lograr con el producto, o lo que el
producto puede hacer por el usuario.

Requerimientos de usuario son muy importantes para el proyecto, si no el más

importante. Ellos son parte de la funcionalidad principal de la producto.
Por esta razón, la determinación de requerimientos de los usuarios por lo general
consumen mucho tiempo.

Hay muchas maneras de expresar los requerimientos del usuario. Estas pueden incluir:
• Casos de uso (use cases)
• Historias de usuario (user stories)
• Storyboards
• Escenarios
 Tipos de Requerimientos
Requerimientos Funcionales
Requerimientos Funcionales, son aquellos comportamientos que el producto desarrollado debería
hacer o apoyar. Estos por lo general son expresados como entradas del producto, salidas del
producto, o una descripción de la conducta en sí misma.

Entradas del Salidas del Descripción de la

producto producto conducta
• Por ejemplo, la entrada • La salida en este • Seria las acciones que se
podrían ser los datos escenario podría ser un llevan a cabo para
relacionados con la correo electrónico de procesar la entradas y
compra en línea de un notificación se lleva a emitir la s salidas
usuario, incluyendo cabo después de la
nombre, dirección, transacción.
artículo comprado, y la
información de pago.
 Tipos de Requerimientos
Requerimientos Funcionales
A menudo, los requerimientos funcionales necesitan ser expresados con profundidad y
especificidad. Diagramas de flujo de información son una técnica gráfica utilizada comúnmente
para mostrar cómo los flujos de datos de todo el sistema y las dependencias de todos los
componentes del sistema. En conjunto, un flujo de información muestra en el diagrama cómo todo
el sistema funciona.

El siguiente es un ejemplo de un diagrama de flujo de información para un cliente utilizando una

tarjeta de crédito con un producto, y donde el información de la tarjeta de crédito se ejecuta antes
de que se genera un recibo por el usuario.
 Tipos de Requerimientos
Requerimientos No Funcionales
Además de los requerimientos funcionales, existen los requerimientos no funcionales
que describen qué tan bien un producto debe funcionar. También se conocen como
requerimientos de calidad por esta razón, requerimientos no funcionales incluyen
cuestiones como:

Facilidad de
La precisión Fiabilidad Seguridad Facilidad de uso Eficiencia Rendimiento
mantenimiento.

Tomando como referencia el ejemplo utilizado en los requerimientos funcionales, un

requerimientos no funcional en el mismo escenario sería: “mensajes de correo
electrónico deben ser entregados a los usuarios dentro de las dos horas de compra”.

Requerimientos no funcionales son por lo general complementarios a los

requerimientos funcionales.
 Tipos de Requerimientos
Requerimientos de Interfaces Externas
Requerimientos de Interfaces Externas se refieren a los
requerimientos relacionados con la forma en que el BD
producto se encuentra dentro de un sistema más clientes
grande. En otras palabras, las interfaces externas no se EEUU

preocupan por el medio ambiente físico del producto,

sino que se ocupa de la relación del producto con otras
entidades fuera del producto.
Flow
Interfaces externas pueden estar representados en el Data
diagramas de flujo de datos que muestran todos los CRM
componentes de un producto, incluyendo entidades BD BD
externas. Estos diagramas de flujo de datos explicitan clientes clientes
referencia al flujo de datos desde otras entidades y la Bolivia México

producto dentro de todo un sistema.

 Tipos de Requerimientos
Requerimientos de Ajustes Físicos
Se refieren a cómo las necesidades de un producto para ser diseñado para funcionar en su entorno
físico.

Por ejemplo, si un producto está siendo desarrollado para el mapeo bajo el agua, es posible que
tenga que ser resistente al agua. Del mismo modo, si el producto fue diseñado para su uso en el
desierto o en la Antártida, lo haría necesitará para soportar y función en esos ambientes.

Restricciones de Desarrollo
Limitaciones de desarrollo afectan todo, desde tecnología de aplicación, documentación y el
proceso utilizado para desarrollar el producto. Por lo general, se refieren a las limitaciones
relacionadas con la creación del producto, tales como los que dispositivos o plataformas serán
soportadas, o la cantidad de memoria, ancho de banda, o el poder de procesamiento del
producto se limita a utilizar.

Es beneficioso para las limitaciones de desarrollo abordarlo lo más tarde posible en la fase de
especificación porque la tecnología cambia rápidamente.
 Cambios en los requerimientos
Controlar el Alcance
Cuando un producto está diseñado, es guiado por un
principio conocido como la visión del producto. La Karl Wiegers
visión del producto es lo que describe el valor de un La visión es un "concepto estratégico a largo
producto para el cliente y su lugar dentro del más plazo de la última finalidad y forma de un nuevo
amplio mercado. Se refiere a la finalidad del producto, sistema, el Alcance es lo que "dibuja la frontera
así como el problema o necesidad el producto se entre lo que esta dentro y fuera para el proyecto".
propone resolver.
Los cambios que se producen en el proyecto deben entrar
en la visión de la producto. En otras palabras, los cambios en
el proyecto no debe cambiar el propósito del producto.

Visiones pueden llegar a ser problemática si no son realistas.

Alcance se define en lo que el proyecto puede alcanzar de
manera realista.

No dar rienda al exceso de promesa de lo que el equipo

puede entregar de forma realista en el producto.

Identificar lo que no será incluido en un producto, por lo que

las expectativas del cliente son claras.
 Cambios en los requerimientos
Controlar el Alcance

Corrupción del alcance

• Sucede cuando el alcance de un proyecto crece es el resultado de un aumento o cambio en los requerimientos.
Por consiguiente, la probabilidad de éxito del proyecto por lo general disminuye significativamente a través del
tiempo.

Preguntar "¿Es este un

Los cambios en lo
requerimientos de software
son comunes y necesitan
contar por Estrategias para
la defensa contra la
corrupción del alcance,
incluyen:
Preguntar al cliente a
Dibujo del alcance priorizar los alcance?" Al refinar los
Hacer requerimientos para
con el cliente a requerimientos para
expectativas evitar gastar el exceso de
través de que el la mayoría de
claras entre el
herramientas tales las más importantes tiempo trabajando
cliente y el como diagramas de se pueden innecesariamente en
equipo. casos de uso. desarrollar características que
temprano. pueden ser mejoradas en
versiones posteriores.

Proporcionar plazos concretos para el desarrollo de los requerimientos con las fechas de inicio y fin claros

Un principio básico del manifiesto ágil es evaluar propuesta de cambio sobre una base de caso por caso y la forma en que el cambio pueden
afectar al proyecto. Los cambios deben ser introducidos a para aumentar el éxito comercial del proyecto. Cualquier cambio aceptado
también debe implicar modificaciones en las estimaciones y los planes para el producto desarrollo.
 Cambios en los requerimientos
Requerimientos y Diseño
En ágil, a veces las líneas entre la formación de requerimientos y el diseño de un producto puede estar borrosa.
Requerimientos se centran en qué, el producto está diseñado para hacer, mientras que el diseño se centra en cómo el
producto puede satisfacer las necesidades del usuario.

Es común que ambos requerimientos y el diseño puedan ser trabajados simultáneamente y los requerimientos
podrían formarse con elementos de diseño en mente. El uso de técnicas tales como dibujos de productos también
pueden ayudar a identificar si los requerimientos encajar en su conjunto y son correctos, consistente y clara.

El gerente de producto de software también debe tener cuidado de no imponer restricciones innecesarias sobre el
producto difuminando requerimientos y diseño.

Estrategias para evitar problemas en el corrupción de requerimientos y diseño incluyen las siguientes preguntas:
 ¿Es la solución sólo una opción posible?
 ¿Es la solución la única posible?
 Es la solución frente al problema equivocado?
 ¿Es la solución justa para atraer interés de los desarrolladores?
 Esta el cliente mas "enfocado a la solución"
Interacción con los Usuarios
 Interacción con clientes
Consideraciones de Usuario
En el diseño de un producto, una de las cosas más Usuarios primarios
importantes para tener en cuenta es que el usuario
• Los principales usuarios son los usuarios finales, o las
final. Los usuarios finales son las personas que personas que utilizarán el producto.
utilizarán el producto, se encuentran entre los
stakeholders (partes interesadas) del proyecto. Usuarios secundarios

Un stakeholders es cualquier persona afectada por o
que tiene un efecto sobre el éxito del proyecto, como
los usuarios finales, clientes, administradores de
usuarios, administradores de sistemas. Un proyecto
exitoso aborda las necesidades de todos los
interesados.
•Son aquellas personas que lo hará de vez en cuando usar el
producto o utilizarlo a través de un intermediario
Usuarios terciarios
•Usuarios terciarios son aquellos que se ven afectados por el uso
del producto o hacer decisiones sobre el producto, tales como
clientes.

Una serie de problemas que pueden surgir en la consideración de usuario interacciones incluyen:

• Los usuarios tienen una incapacidad para expresar lo que necesitan

• Los usuarios están sesgadas por las experiencias anteriores
• Los desarrolladores a veces tienen problemas para ver a través de un punto de vista del
usuario, debido a su avanzada conocimiento de la tecnología
 Interacción con clientes
Consideraciones de Usuario
Creación de una interfaz intuitiva y fácil de usar
es la clave para abordar muchos de estos
problemas. Una buena estrategia a tener en
cuenta es diseñar un producto tanto para
usuarios principiantes y expertos usuarios. En
general, el diseño será entonces adaptarse a los
Limitaciones perceptuales o sensoriales
• Son causadas por restricciones de los cinco
sentidos. La ceguera de color es un ejemplo de
una limitación sensorial.
Limitaciones físicas

usuarios intermedios también. • Afectan cómo un usuario físicamente interactúa con o

utiliza un producto. Un ejemplo es la izquierda o diestro.
En el diseño de software, también es importante
Limitaciones cognitivos o de memoria
considerar el numerosos usuarios se enfrentan a
limitaciones. Estas limitaciones están • Donde la gente puede Sólo recordar tantas cosas a la vez.
relacionados con las limitaciones humanas.
limitaciones culturales

George A. Miller, uno de los fundadores del • Que abarcan lo diferente antecedentes culturales de los
usuarios potenciales pueden afectar interpretación de los
campo de la cognitiva psicología, descubrió elementos de diseño, como símbolos y iconos, diseño,
que los seres humanos tienen un límite multimedia, y las necesidades de traducción.
promedio de corto plazo capacidad de
memoria. La gente puede recordar entre cinco
y nueve cosas, con siete siendo la media. Las
distracciones limitan la memoria aún más.
 Interacción con clientes
La participación de los clientes y usuarios
En la obtención de requerimientos se enfatizó la
importancia de involucrar a los clientes. Un buen
gestor de producto de software y equipo de
desarrollo no se limitan a recoger las ideas de los
clientes, colaborar activamente con los clientes.
En consecuencia, de las discusiones las ideas
cliente puede cambiar desde el inicio, con el
aporte de tanto el equipo como el cliente, el
mejor producto posible puede ser hecho.
Requerimientos también pueden provenir de
otras fuentes, incluyendo:
• Entrevistas con los usuarios finales.
• Estudios de viabilidad con grupos focales.
• Observar cómo los usuarios finales utilizan
el producto.
• Consultar los productos anteriores.
Al participar en la discusión, los clientes son
conscientes de metas y plazos realistas, ¿qué se hará
y que no se hace en el producto y, posteriormente,
se pueden priorizar requerimientos .
Una buena manera de involucrar a los clientes y para
entender su requerimientos es hacer buenas
preguntas!
Las buenas preguntas son abiertas y no se pueden
responder con un simple sí o no. Las preguntas que
preguntan "¿por qué?", ​son particularmente buenas,
porque fomentan un cliente para analizar e identificar
su núcleo necesariamente, da una buena explicación
de lo que hace esta pregunta valiosa.
"¿Qué quieres?" O "¿Cuáles son sus necesidades?"
son preguntas menos útiles porque son demasiado
amplias y no proporcionan buena estructura para la
comprensión de las necesidades del cliente.
 Interacción con clientes
La participación de los clientes y usuarios
Los requerimientos deben ser revisados ​a
menudo con el cliente. Después de la primera
reunión, por ejemplo, es una buena idea para
mostrar al cliente maquetas y prototipos
producidos a partir de las reuniones iniciales.
Es una buena práctica enumerar los
requerimientos con identificadores
únicos en todo el proyecto, por lo que
son fáciles de hacer referencia a ellos
mientras el proyecto se desarrolla!
Una herramienta importante para la
interacción con los clientes es el uso y
creación de un glosario. Un glosario es
una lista de términos y su las definiciones
que se relacionan específicamente con el
producto que se está construyendo.
En resumen, Involucrar al cliente a través de reuniones y
los aspectos revisión continua de requerimientos.
clave a tener
en cuenta en
la interacción
Utilice otras fuentes de información, como los
usuarios finales.
del cliente
incluyen:
Pida buenas preguntas.
Sea firme y abierto en las interacciones de los
clientes.
Comunicar claramente los requerimientos
realistas y líneas de tiempo para gestionar las
expectativas del cliente.
Use términos comunes a través de glosarios.
Realizar un seguimiento de los requerimientos
Recuerde que es responsabilidad del gestor de
producto de software comunicar claramente los pros y
contras de requerimientos , pero el cliente es el que
debe tomar las decisiones de nivel clave de
requerimientos
 Interacción con clientes
Casos de Uso
Los casos de uso, fue desarrollado por Ivar
Jacobson en 1986, son una buena herramienta Nombre
para la comprensión de un producto. Pueden Name
definirse como una forma de identificar, aclarar y Actores participantes
organizar los detalles de una tarea dentro de un Participating actors

producto. Metas
Goals

Es una manera de explicar un conjunto de Disparaodores

Triggers
interacciones secuenciales que los usuarios
pueden tener con las funcionalidades de un Pre-condiciones
Pre-conditions
producto.
Post-condiciones
Post-Condition
Un buen caso un uso describe la tarea propuesta
Flujo Básico
desde el punto de vista de la participación de un Basic Flow
actor (por lo general un usuario), y no requiere Flujo alternativo
tener un profundo conocimiento de la tecnología. Alternate Flow

Excepción
Exception

Cualidades
Qualities
 Interacción con clientes
Casos de Uso
Un Diagrama de Casos de Uso, es útil para describir
Ejemplo de caso de uso:
los casos de uso de un producto, Diagramas de Casos
de Uso son de alto nivel, muestran representaciones
visuales que describen todas las tareas del producto
que se está creando. Actores y sus casos de usos
respectivos usos también están representados.

En general, el diagrama debe mostrar todo el

producto, tareas que puedan llevarse a cabo
mientras participa con el producto y los roles
establecidos para el producto.
Interacción con clientes
Casos de Uso
 Interacción con clientes
Wireframes
Una de las técnicas más importantes del desarrollo
de productos es el uso de wireframes. Un wireframe,
también conocido como un maquetas (mockups), se
puede considerar como una especie de modelo
temprano. Es una representación visual básica del
producto.
Wireframes se utilizan para muchos propósitos.
Éstas incluyen:
Aunque es una representación visual, un
aspecto clave de wireframes es su sencillez.
Wireframes no están destinados a ser una
demostración de la interfaz de un producto sino
esbozar funcionalidades básicas y tareas de
usuario final.

• Obtener una idea de lo que será desarrollado.

• Mostrar ideas a los clientes o usuarios y
fomentar su retroalimentación y participación.
• Fomentan la comunicación entre el equipo de
desarrollo.
• Ayudar al cliente o los usuarios a comunicarse
con el gestor de producto de software y equipo
(algunas personas les puede resultar más fácil
esbozar sus ideas para describirlos).
Herramientas: Balsamiq, Flair Builder
 Interacción con clientes
Storyboards
Otra técnica utilizada para ayudar en la formación de los requerimientos son los storyboards. En el
desarrollo de software, storyboards son representaciones secuenciales y visuales de una interacción
con el producto de software. Storyboards ayudan a obtener más requerimientos del producto y
refinar los ya existentes.
Hay dos tipos principales de storyboards:

Primer tipo

El primer tipo storyboards describe la experiencia

de usuario de alto nivel con el producto. Este de
tipo guión gráfico, tiende a parecerse a una tira
cómica, donde cada acción se ilustra en la
secuencia o flujo de la utilización de un producto,
incluida la decisión de utilizar el producto y los
resultados al final de una interacción.

Si se ofrecen varias características en el producto,

cada uno debe tener un guión gráfico.
 Interacción con clientes
Storyboards
Otra técnica utilizada para ayudar en la formación de los requerimientos son los storyboards. En el
desarrollo de software, storyboards son representaciones secuenciales y visuales de una interacción
con el producto de software. Storyboards ayudan a obtener más requerimientos del producto y
refinar los ya existentes.
Hay dos tipos principales de storyboards.

Primer tipo

• Asegurar que todo el equipo de desarrollo está

en la misma página.
• Mejorar la posibilidad de identificar
características para mejorar o crear en el
producto de software.
• Asegurar la visión de que el producto sigue
siendo claro en su uso.
• Uso en marketing o demostraciones.
Interacción con clientes
Storyboards
Segundo tipo

El segundo tipo de guión gráfico combina

wireframes y flujo básico de casos de uso con el
fin de mostrar cómo el usuario final interactúa
con la interfaz de usuario del producto en
detalle. Está más relacionado con el diseño de
software.
Tiene muchos usos potenciales, que incluyen:
• Ayudar al equipo de desarrollo para diseñar
requerimientos.
• Ayudar a identificar lo que podría estar
demasiado complicado o no tomado en cuenta
en el apoyo a las tareas que los usuarios realizan
• Asegurar el equipo de desarrollo está al tanto de
las funcionalidades y feel del producto.
• Guiar a los escritores técnicos en la creación de
materiales de capacitación.
Interacción con clientes
Storyboards
Escribiendo los Requerimientos
Escribiendo los Requerimientos

Requerimientos Ágiles
Los requerimientos pueden ser expresadas a través de técnicas tales como casos de uso,
wireframes y storyboards, pero también se pueden expresar a través de muchos formatos escritos.

Necesidades y requerimientos del cliente se pueden expresar dentro de la filosofía del Software
de Desarrollo Ágil. Estos principios apoyan la creencia en que el software Ágil es dinámico.

En concordancia con esta filosofía, los clientes suelen cambiar de opinión acerca de la
funcionalidad del producto. Esto puede ocurrir incluso en medio del desarrollo.

Interacciones cara a cara
con los clientes es clave
para asegurar que los
requerimientos están
correctos, aunque ellos
cambien.
Los requerimientos son
una parte integral de ágil.
A su vez, si un principio
Ágil es seguido en la
creación de los
requerimientos, la calidad
es mayor.
Los requerimientos
cambiantes deben ser
bienvenidos y esperados.
La capacidad de dar la
bienvenida a los
requerimientos cambiantes
puede hacer la diferencia
entre el éxito o el fracaso de
un proyecto.
Escribiendo los Requerimientos

Historias de Usuario (User History)

Historias de usuario (User History) son una técnica importante utilizada para expresar los
requerimientos, al igual que los casos de uso, wireframes y storyboards.

Historias de usuario son especiales debido a que utilizan un formato coherente para expresar los
requerimientos, que es fácil de escribir, leer y evaluar.

“Como ‘quién,’ quiero ‘qué,’ asi que[por lo que..] ‘por qué.’”

“As a ‘who,’ I want to ‘what,’ so that ‘why.’”

quién qué por qué

El "quién" del requerimiento
es el rol del stakeholder
(interesado) de quien el
requerimiento esta siendo
formado.
El requerimiento se debe
escribir como si fuera desde
el punto de vista de esta
persona.
Como cliente,.
El "qué" del
requerimiento es la
tarea especifica o
funcionalidad que el
stakeholder(interesado)
quiere lograr mediante
el uso del producto.
quiero ser capaz de identificar
las cantidad de calorías de las
comidas
El "por qué" del
requerimiento destaca
las metas o visiones del
producto, y ofrece
información sobre el
valor o beneficio del
requerimiento.
así puedo elegir que comida
ordenar.
Escribiendo los Requerimientos

Historias de Usuario (User History)

Historias de usuario son útiles, ya que proporcionan una
manera clara y estructurada de expresar los requerimientos
sin utilizar demasiados detalles técnicos.

A diferencia de los requerimientos libremente formados,

historias de usuario garantizan el "quién", "qué" y "por qué"
de un re requerimiento sean siempre tomados en cuenta.

Historias de usuario también son útiles porque son cortas y

pueden ser fácilmente escritas en tarjetas físicas o notas
adhesivas. Esta práctica permite una fácil organización de las
necesidades, que pueden ser re-organizadas cuando los
requerimientos cambian. Historias de los usuarios pueden
ser evaluadas utilizando el
Aunque los clientes deben escribir las historias de usuario, ya nemotécnico INVEST.
que conocen mejor lo que quieren, un gestor producto de
software a menudo ayuda a escribir historias de los usuarios, Las buenas historias de usuario
ya que son más experimentado en hacerlo. muestran un requerimiento
específico de software en el
producto.
Escribiendo los Requerimientos

Historias de Usuario (User History)

I
Independent
El requerimiento puede existir fuera de otras historias de usuario y seguir siendo significativo. Esto
permite que los requerimientos y sus historias de usuario ser reorganizados libremente si es necesario. Si una historia de
Negociable usuario contiene
Historias de los usuarios también deben ser lo suficientemente generales para el equipo de desarrollo y el descripciones que
N cliente trabajen en torno a su ejecución. Ellos no deben centrarse en los detalles técnicos específicos. En
cambio, habría que centrarse en los aspectos más importantes de los requerimientos, mientras que
recordar que estos podrían cambiar.
son demasiado
vagos o amplios, y
si es difícil estimar
V Valioso
Historias de los usuarios deben aportar valor al cliente. cuánto tiempo va a
tomar o cómo se
Estimable puede hacer, es
E Debería ser posible estimar la cantidad de tiempo que se necesitaría para diseñar e implementar el
requerimiento de la historia de usuario. probable que sea
una historia de
Pequeño (Small)
usuario épica.
S Una historia de usuario debe ser pequeña, ya que está destinada a ser desarrollada en un corto período
de tiempo. Si a la hora de diseñar e implementar un requerimiento es incierto, la historia de usuario es
probablemente demasiado grande, por lo que debe ser dividido en historias más pequeñas y manejables .

Testeable

T Historias de los usuarios deben ser verificables en contra de un conjunto de criterios con el fin de
determinar si es "Done", lo que significa que la historia de usuario ha logrado lo que se propuso hacer, y
no es necesario seguir trabajando. Esto se logra generalmente con pruebas de aceptación.
Escribiendo los Requerimientos
Historias de Usuario (User History)
Historia de Usuario Épica
Las historias suelen producirse al inicio de un proyecto cuando
el producto aún está en desarrollo y todavía no tiene forma
definida.
Esto es debido al patrón conocido como el "cono de
incertidumbre", lo que sugiere que las estimaciones de tiempo
para desarrollar una historia de usuario es menos precisa
cuando esta más lejos en el futuro la funcionalidad que será
diseñada para ser desarrollada. Incluso los equipos de
desarrollo experimentados encuentran historias de usuario
épicas.
Con el fin de evitar la escritura de historias épicas de usuario, es
importante ser capaz de identificar cuando una ha sido creada.
Si una historia épica ha sido identificada, puede ser dividida en
historias más pequeñas, que pueden ser estimadas. Una buena
estrategia para evitar historias épicas de usuario es
proporcionar información suficiente para que un desarrollador
entienda cómo implementarlo, pero no tanta información que
los detalles de implementación se convierten en parte de la
historia.
"Como cliente, quiero pagar mi cuenta, así
que puedo saldar lo que le debo
rápidamente. "
Esta historia de usuario podría desglosarse en otros más
pequeños, tales como:
1. "Como cliente, quiero ser capaz de ver mi cuenta
con todos los elementos en orden, por lo que puedo
ver la cantidad que mi pedido va a costar".
2. "Como cliente, quiero ser capaz de seleccionar la
opción "pagar ahora "cuando veo mi cuenta, así que
puedo pagar la cuenta inmediatamente."
3. "Como cliente, quiero ser capaz de ingresar mis
detalles de pago para tarjetas de crédito VISA y
MasterCard, así que puedo pagar de la manera más
conveniente."
Escribiendo los Requerimientos
Historias de Usuario (User History)
Pruebas de Aceptación
Una prueba de aceptación se utiliza para verificar si se han
cumplido los requerimientos de una historia de usuario. Las
pruebas de aceptación se utilizan a menudo en la parte
comprobable del mnemónico INVEST. Una historia de usuario
se considera satisfecho si se pasa la prueba.
Las pruebas de aceptación son evaluados en base a un
conjunto de aceptación criterios. Los criterios de aceptación
son simples con condiciones específicas utilizadas para verificar
si se ha implementado hay una historia de usuario
correctamente.
Un lenguaje claro y directo se debe utilizar en la creación de
pruebas de aceptación.
Cada prueba deberá evaluar una condición verificable que
constituye una pequeña parte de la historia de usuario. Si se
pasan todas las pruebas, a continuación, se pasa el criterio de
aceptación. Si se pasan todas las pruebas de aceptación de
todos los criterios de aceptación de las historias de usuario,
entonces el historia de usuario se considera probado con éxito.
Ejemplo
"Como cliente, quiero ser capaz de ingresar más
detalles de pago con tarjetas de crédito VISA y
MasterCard, así que puedo pagar con el método
conveniente", ejemplos de criterios de aceptación
incluyen:
1. El pago puede hacerse con tarjeta de crédito
VISA.
2. El pago puede hacerse con tarjeta de crédito
MasterCard.
3. Pago se puede hacer uso de un servicio financiero
en línea.
4. Al pagar con tarjeta de crédito, completando el
"número de tarjeta" detecta automáticamente el
tipo de tarjeta.
5. El cliente sólo ve los campos de entrada
correspondientes, dependiendo del método de
pago seleccionado.
Para cambiar un criterio en una prueba de aceptación,
es útil crear un unos de pasos. Por ejemplo, para "El
pago puede hacerse con tarjeta de crédito VISA," las
pruebas pueden ser:
• Inserte una tarjeta VISA en un lector de chip.
• Introduzca el número PIN VISA.
• Confirmar fue aceptado el pago.
Pasando por estos pasos verifica el criterio de
aceptación.
Escribiendo los Requerimientos

Product Backlog
Un Product Backlog es un conjunto o una lista de software
features que el gestor de producto de software y el equipo de
desarrollo planean para desarrollar para un producto. Son un
medio de organización del trabajo, dando prioridad a las
tareas dentro del proyecto, y la planificación de esas
prioridades.

Product Backlog es una técnica/práctica popular debido a que

proporcionan una gran flexibilidad para clientes y equipos de
desarrollo. Ellos son fundamentales para Scrum y por lo tanto,
Ágil.

El siguiente paso en la creación de un Product Backlog es

priorizar las historias de usuario y (features)características.
El proceso de priorización ayuda a los clientes a identificar sus
necesidades y deseos. También ofrece a los desarrolladores
perspectiva y enfoque, poniendo de relieve lo que es más
importante en un proyecto.
 Escribiendo los Requerimientos

Product Backlog
Como priorización es importante para todo el equipo, priorizando historias
de usuario en el Product Backlog se consigue mejor con discusiones con los
clientes, el gestor del producto de software, y el equipo de desarrollo. ¿Por
qué una historia de usuario es importante? debe ser claro a todo el mundo a
través de estas discusiones.

Usando Product Backlog, el equipo de desarrollo puede comenzar a

planificar el proyecto con prioridades como puntos de referencia. Historias de
usuario son agrupadas del Product Backlog a realizarse en un intervalos de
tiempo, estos intervalos se conocen como sprints.

El características mas importantes de Product Backlog deben terminarse

antes mientras que las menos importantes se pueden acabar más tarde.

Scrum se centra en el desarrollo de un sprint a la vez, aunque el sprint en el

desarrollo no debería cambiar, son capaces de cambiar. Al final de un sprint,
los clientes pueden evaluar el trabajo realizado y añadir nuevas historias de
usuarios o requerimientos para el producto, o el cambio de la prioridad de
las historias de usuario o necesidades existentes. El siguiente Sprint se
puede ajustar en consecuencia.

Por lo tanto, los Product Backlog cambiarán con el tiempo y pueden

convertirse en pedidos más pequeños, más grandes, o que han cambiado.
Tal adaptabilidad y versatilidad se fomenta en los métodos ágiles.
Escribiendo los Requerimientos

Product Backlog
Un Product Backlog es un conjunto o una lista de software
features que el gestor de producto de software y el equipo de
desarrollo planean para desarrollar para un producto. Son un
medio de organización del trabajo, dando prioridad a las
tareas dentro del proyecto, y la planificación de esas
prioridades.

Product Backlog es una técnica popular debido a que

proporcionan una gran flexibilidad para clientes y equipos de
desarrollo. Ellos son fundamentales para Scrum y por lo tanto,
Ágil.

Features en el Product Backlog incluyen Crear Product Listar User Enumerar los Listar otros
tareas de trabajo (trabajos físicos que se Backlog History User History Features
deben hacer en el proyecto, pero no
necesariamente están relacionados con
el desarrollo de las funcionalidades del Ayuda a determinar
Priorizar los User Ayuda a los clientes Ofrece perspectiva qué características
producto), tareas de conocimiento History / a identificar sus a los sobre lo que se puede lograr en
necesidades y es más importante un proyecto con la
(trabajo para las partes del proyecto que Features deseos. en un proyecto. tecnología y los
deben ser aprendidas), bugs (errores en recursos dados.
el código de producto ), y más
comúnmente, historias de usuario. Prioridades como Agrupar historias de
Determinar los
Planificar puntos de usuarios por
sprints
referencia unidades de trabajo
Escribiendo los Requerimientos

Story Maps (Mapas de historias)

Story Maps se utilizan para organizar los
requerimientos y ayudar a estructurar un
proyecto. Story Maps apoyan el cambio en un
nivel más alto que el Product Backlog.

Representan el Product Backlog de una

manera visual, con historias de usuarios
agrupados en específicas actividades o
categorías. Al cubrir y dar prioridad a las
historias de usuario a través de múltiples
categorías, mapas de historias ofrecen vistas
integradas del producto que se está
desarrollando.
Beneficios Beneficios

•Simplificar priorización de las historias de
usuario.
•Dar al Product Backlog una sensación visual de
seguimiento.
•Dar perspectiva sobre cómo las historias de
usuario pueden relacionarse entre sí.
•Ayudar a identificar lo que podría faltar en cada
categoría.
•Proporcionar contexto para desarrolladores mostrando que otra sencilla
funcionalidad es mejor implementarse antes del trabajo más complejo.
•Proporcionar una visión integrada del producto al no permitir que se centren en
una sola categoría, haciendo hincapié en las múltiples funcionalidades (o categorías)
de la mayoría de los productos.
•Dar una mejor comprensión de cómo el producto va a desarrollar y encajar sobre
etapas, es posible ver cómo un producto evolucionará fila por fila, lo que podría
ahorrar tiempo en el transcurso del proyecto.

Tools: FeatureMap, Jira, Trello

Escribiendo los Requerimientos

Story Maps (Mapas de historias)

Calidad en los Requerimientos
Calidad en los Requerimientos

Criterio para las Historias de Usuarios

Es posible evaluar la calidad de las historias de usuario utilizando un conjunto de criterios.

Historias de usuario de calidad son importantes para guiar el desarrollo con el fin de evitar errores y
confusiones. En consecuencia, no debe haber historias de usuario que faltan, y historias de usuario existente
debe ser fácil de entender y libre de ambigüedad.

Correcto Completa Clara Consistente Verificable

Historias de los Una historia de usuario Historias de usuario Este criterio requiere •Historias de los
usuarios deben ser completa es aquella son claras si son fáciles la verificación de que usuarios deben ser
correctas o el equipo donde se incluyen de entender y sólo los requerimientos no comprobables o
de desarrollo crearán todos los pueden ser están en conflicto medibles de alguna
funcionalidades que no requerimientos interpretadas de una entre sí. manera, con el fin de
están en línea con la necesarios para manera. determinar si cada
visión del cliente. Se describir el problema. Ejercicios de Revisión requerimiento ha sido
pierde tiempo tanto la Si los requerimientos Técnica y ajustes de satisfecho. A menudo,
creación de funciones faltan, esas requerimientos se la cuantificación de
incorrectas y la características se utilizan para reducir los aspectos de los
eliminación de ellas perderán en el ambigüedades. requerimientos ayuda
más tarde. producto final. Story Personas ajenas al a hacerlos verificable.
Maps se utilizan a proyecto, Wireframes
menudo para y Storyboards, entre
identificar los otras herramientas
requerimientos que visuales, también
faltan. pueden ayudar a
eliminar
ambigüedades.
Calidad en los Requerimientos

Criterio para las Historias de Usuarios

Es posible evaluar la calidad de las historias de usuario utilizando un conjunto de criterios.

Historias de usuario de calidad son importantes para guiar el desarrollo con el fin de evitar errores y
confusiones. En consecuencia, no debe haber historias de usuario que faltan, y historias de usuario existente
debe ser fácil de entender y libre de ambigüedad.

Factible Trazabilidad Manejable Sencillo

Una historia de usuario
factible cuando puede ser
implementada de manera
realista, cuando se tienen
en cuenta las limitaciones
del producto. Esto incluye
la tecnología, las
herramientas, los recursos
y el personal disponible,
así como el presupuesto y
el calendario.
Historias de los usuarios
deben ser trazables, lo que
significa que cada
requerimiento en una
historia de usuario se debe
ser capaz de realizarle un
seguimiento a lo largo del
proyecto.
Una técnica en la que los
identificadores únicos son
asignados a cada
requerimiento se utiliza a
menudo para facilitar el
seguimiento. Los
identificadores únicos
pueden ser tan simples
como números
secuenciales.
Una buena historia de
usuario es manejable, lo
que significa que es
idealmente independiente
de otras historias de
usuario y se puede
cambiar sin un impacto
excesivo en otras historias
de usuario, esto no
siempre es realista por lo
que la agrupación o la
vinculación de historias de
usuario a menudo ayuda a
mantenerlos manejables.
Historias de los usuarios
deben ser simples, lo que
significa que deben
mantenerse minimalista.
Una buena historia de
usuario se centra sólo en
la función que será
implementada; que no
hace referencia a la forma
en que se llevará a cabo.
Detalles de diseño
innecesarios también no
se incluyen en las buenas
historias de usuario. De
hecho, una buena historia
de usuario debe ser
independiente de la
tecnología.
Calidad en los Requerimientos

Requerimientos Ambiguos
Es posible evaluar la calidad de las historias de usuario utilizando un conjunto de criterios.

Historias de usuario de calidad son importantes para guiar el desarrollo con el fin de evitar errores y
confusiones. En consecuencia, no debe haber historias de usuario que faltan, y historias de usuario existente
debe ser fácil de entender y libre de ambigüedad.

"Un" o Las palabras "un" o "unas" no son específicas. Ellos podrían referirse a singular o plural de un artículo o evento.
"unas" Es mejor utilizar un cuantificador.

"Después" o Las palabras "después" o "antes", son vagas pueden describir bien la instancia inmediata después o antes del evento o el
"antes de" objeto en cuestión, pero que también podría referirse a cualquier instancia o después de antes del evento o el objeto en
cuestión. Es mejor para dar una descripción firme de la posición exacta en la secuencia que se produce un evento u objeto.

"Todo" El mundo de "todos" es confuso en algunas frases como no está claro lo que se conoce. Por ejemplo, "Todo vehículos en el
estacionamiento deben estar autorizados por una propietario "puede significar:
• un propietario debe conceder licencias a todos los vehículos en el estacionamiento
• cada vehículo está autorizada por un propietario diferente
• cada vehículo está autorizado por el propietario, sino un propietario podrá dar licencia a más de un vehículo
Es una buena práctica para ser lo más específico posible.

"Y" La palabra "y" puede ser ambigua porque podría enumerar dos condiciones independientes juntos en una frase, o podría
referirse a dos condiciones necesaria para que algo suceda. Si dos condiciones independientes por separado se han unido
es mejor romper esto en dos.

"Ambos" La palabra "ambos" puede ser confuso, ya que podría no estar claro cual sustantivo que se conoce de qué manera. Por
ejemplo, "Ambos restaurantes están a cargo de una gerente "puede significar:
• Cada restaurante está dirigido por una gerente diferente
• Un gerente está dirigiendo ambos restaurantes.
Es importante ser específico.
Calidad en los Requerimientos

Requerimientos Ambiguos
Ahora cada siguiente para desde ultimo sólo o mismo debería de ellos hasta nosotros cuando

Hay muchas otras palabras que pueden crear requisitos ambiguos, pero los mencionados anteriormente son los
más comunes.

Lenguaje no claro también puede surgir durante las conversaciones entre el cliente, el gestor de producto de
software y equipo de desarrollo. Es importante para el gestor de producto de software hacer preguntas para
aclarar las discusiones.

Las buenas preguntas incluyen el examen de la verdad de los hechos presentados y pidiendo explicaciones
sobre términos inciertos o ciertos percibidos en las necesidades y requerimientos.

La determinación de lo que significa para el cliente y por qué es importante la incrementa la calidad de los
requerimiento.
GRACIAS!