Está en la página 1de 52

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 3. Priorización de Requerimientos 4. Analisis de Requerimientos 5. Gestión de Requerimientos

Se trata de la organización y re-


A menudo, los requerimientos se Una vez la visión de lo que hay El proceso de examinar el listado organización de requerimientos
describen primero a través de que hacer para el proyecto se ha de requerimientos de un y, posiblemente, la reutilización
notas de encuentros con los establecido a través de la proyecto para asegurarse de que de los subconjuntos de los
clientes. obtención y expresión de son claros, completos y requerimientos en diferentes
Es mejor y más concreto usar requerimientos, es importante coherentes es conocido como el etapas.
representaciones para expresar dar prioridad a las necesidades análisis de requerimientos.
los requerimientos del cliente, especialmente en la
metodología Scrum. Preguntas Proceso continuo
para ayudar a establecer Un proyecto debe ser
prioridades incluyen: continuamente evaluado y los
requerimientos mejorado. Seguimiento de las prioridades,
Casos de uso
¿Qué requerimientos DEBEN análisis, y cambios en los
realizarse para que el proyecto y requerimientos .
Ayuda a resolver requerimientos
producto tenga éxito? conflictivos o identificar
Historias de usuario problemas entre requerimientos Todo esta conectado, si algo
¿Qué requerimientos DEBERIAN cambia en un requerimiento
hacerse? En otras palabras, lo que afectará a otros y el desarrollo del
es importante, pero no es tan Asegura que los requerimientos producto.
crítico podría ser satisfecho otra identificados reflejan y se
Storyboards manera o en un momento relacionan con el producto que se
posterior en el proyecto? está construyendo

¿Qué requerimientos se
PODRIAN hacer para mejorar el
proyecto o producto pero no es
necesario?
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 Preguntar al cliente a
Dibujo del alcance priorizar los alcance?" Al refinar los
requerimientos de software Hacer requerimientos para
son comunes y necesitan con el cliente a requerimientos para
expectativas evitar gastar el exceso de
través de que el la mayoría de
contar por Estrategias para claras entre el
herramientas tales las más importantes tiempo trabajando
la defensa contra la cliente y el como diagramas de se pueden innecesariamente en
corrupción del alcance, equipo. casos de uso. desarrollar características que
incluyen: 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 •Son aquellas personas que lo hará de vez en cuando usar el
producto o utilizarlo a través de un intermediario
que tiene un efecto sobre el éxito del proyecto, como
los usuarios finales, clientes, administradores de Usuarios terciarios
usuarios, administradores de sistemas. Un proyecto
exitoso aborda las necesidades de todos los •Usuarios terciarios son aquellos que se ven afectados por el uso
del producto o hacer decisiones sobre el producto, tales como
interesados. 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 Limitaciones perceptuales o sensoriales
es la clave para abordar muchos de estos • Son causadas por restricciones de los cinco
problemas. Una buena estrategia a tener en sentidos. La ceguera de color es un ejemplo de
cuenta es diseñar un producto tanto para una limitación sensorial.
usuarios principiantes y expertos usuarios. En
general, el diseño será entonces adaptarse a los 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 Al participar en la discusión, los clientes son
importancia de involucrar a los clientes. Un buen conscientes de metas y plazos realistas, ¿qué se hará
gestor de producto de software y equipo de y que no se hace en el producto y, posteriormente,
desarrollo no se limitan a recoger las ideas de los se pueden priorizar requerimientos .
clientes, colaborar activamente con los clientes.
En consecuencia, de las discusiones las ideas
cliente puede cambiar desde el inicio, con el Una buena manera de involucrar a los clientes y para
aporte de tanto el equipo como el cliente, el entender su requerimientos es hacer buenas
preguntas!
mejor producto posible puede ser hecho.
Requerimientos también pueden provenir de Las buenas preguntas son abiertas y no se pueden
otras fuentes, incluyendo: responder con un simple sí o no. Las preguntas que
preguntan "¿por qué?", ​son particularmente buenas,
porque fomentan un cliente para analizar e identificar
• Entrevistas con los usuarios finales. su núcleo necesariamente, da una buena explicación
• Estudios de viabilidad con grupos focales. de lo que hace esta pregunta valiosa.
• Observar cómo los usuarios finales utilizan
el producto. "¿Qué quieres?" O "¿Cuáles son sus necesidades?"
• Consultar los productos anteriores. 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 En resumen, Involucrar al cliente a través de reuniones y
menudo con el cliente. Después de la primera los aspectos revisión continua de requerimientos.
reunión, por ejemplo, es una buena idea para clave a tener
en cuenta en
mostrar al cliente maquetas y prototipos la interacción
Utilice otras fuentes de información, como los
usuarios finales.
producidos a partir de las reuniones iniciales. del cliente
incluyen:
Pida buenas preguntas.

Es una buena práctica enumerar los


Sea firme y abierto en las interacciones de los
requerimientos con identificadores clientes.
únicos en todo el proyecto, por lo que
son fáciles de hacer referencia a ellos Comunicar claramente los requerimientos
mientras el proyecto se desarrolla! realistas y líneas de tiempo para gestionar las
expectativas del cliente.

Use términos comunes a través de glosarios.


Una herramienta importante para la
interacción con los clientes es el uso y Realizar un seguimiento de los requerimientos
creación de un glosario. Un glosario es
una lista de términos y su las definiciones Recuerde que es responsabilidad del gestor de
que se relacionan específicamente con el producto de software comunicar claramente los pros y
contras de requerimientos , pero el cliente es el que
producto que se está construyendo. 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 Aunque es una representación visual, un
de productos es el uso de wireframes. Un wireframe, aspecto clave de wireframes es su sencillez.
también conocido como un maquetas (mockups), se Wireframes no están destinados a ser una
puede considerar como una especie de modelo demostración de la interfaz de un producto sino
temprano. Es una representación visual básica del esbozar funcionalidades básicas y tareas de
producto. usuario final.
Wireframes se utilizan para muchos propósitos.
Éstas incluyen:

• 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.

Los requerimientos
Interacciones cara a cara Los requerimientos son cambiantes deben ser
con los clientes es clave una parte integral de ágil. bienvenidos y esperados.
para asegurar que los A su vez, si un principio La capacidad de dar la
requerimientos están Ágil es seguido en la bienvenida a los
correctos, aunque ellos creación de los requerimientos cambiantes
cambien. requerimientos, la calidad puede hacer la diferencia
entre el éxito o el fracaso de
es mayor.
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 El "qué" del El "por qué" del
(interesado) de quien el requerimiento es la requerimiento destaca
requerimiento esta siendo tarea especifica o las metas o visiones del
formado. funcionalidad que el producto, y ofrece
stakeholder(interesado) información sobre el
El requerimiento se debe quiere lograr mediante valor o beneficio del
escribir como si fuera desde el uso del producto. requerimiento.
el punto de vista de esta
persona.
quiero ser capaz de identificar
así puedo elegir que comida
Como cliente,. las cantidad de calorías de las
ordenar.
comidas
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 "Como cliente, quiero pagar mi cuenta, así
el producto aún está en desarrollo y todavía no tiene forma que puedo saldar lo que le debo
definida. rápidamente. "
Esto es debido al patrón conocido como el "cono de Esta historia de usuario podría desglosarse en otros más
incertidumbre", lo que sugiere que las estimaciones de tiempo pequeños, tales como:
para desarrollar una historia de usuario es menos precisa 1. "Como cliente, quiero ser capaz de ver mi cuenta
cuando esta más lejos en el futuro la funcionalidad que será con todos los elementos en orden, por lo que puedo
diseñada para ser desarrollada. Incluso los equipos de ver la cantidad que mi pedido va a costar".
desarrollo experimentados encuentran historias de usuario
2. "Como cliente, quiero ser capaz de seleccionar la
épicas. opción "pagar ahora "cuando veo mi cuenta, así que
puedo pagar la cuenta inmediatamente."
Con el fin de evitar la escritura de historias épicas de usuario, es
3. "Como cliente, quiero ser capaz de ingresar mis
importante ser capaz de identificar cuando una ha sido creada. detalles de pago para tarjetas de crédito VISA y
Si una historia épica ha sido identificada, puede ser dividida en MasterCard, así que puedo pagar de la manera más
historias más pequeñas, que pueden ser estimadas. Una buena conveniente."
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.
Escribiendo los Requerimientos

Historias de Usuario (User History)


Pruebas de Aceptación Ejemplo
Una prueba de aceptación se utiliza para verificar si se han "Como cliente, quiero ser capaz de ingresar más
cumplido los requerimientos de una historia de usuario. Las detalles de pago con tarjetas de crédito VISA y
MasterCard, así que puedo pagar con el método
pruebas de aceptación se utilizan a menudo en la parte
conveniente", ejemplos de criterios de aceptación
comprobable del mnemónico INVEST. Una historia de usuario incluyen:
se considera satisfecho si se pasa la prueba. 1. El pago puede hacerse con tarjeta de crédito
VISA.
2. El pago puede hacerse con tarjeta de crédito
Las pruebas de aceptación son evaluados en base a un MasterCard.
conjunto de aceptación criterios. Los criterios de aceptación 3. Pago se puede hacer uso de un servicio financiero
son simples con condiciones específicas utilizadas para verificar en línea.
si se ha implementado hay una historia de usuario 4. Al pagar con tarjeta de crédito, completando el
"número de tarjeta" detecta automáticamente el
correctamente. tipo de tarjeta.
5. El cliente sólo ve los campos de entrada
Un lenguaje claro y directo se debe utilizar en la creación de correspondientes, dependiendo del método de
pago seleccionado.
pruebas de aceptación.
Para cambiar un criterio en una prueba de aceptación,
es útil crear un unos de pasos. Por ejemplo, para "El
Cada prueba deberá evaluar una condición verificable que pago puede hacerse con tarjeta de crédito VISA," las
constituye una pequeña parte de la historia de usuario. Si se pruebas pueden ser:
• Inserte una tarjeta VISA en un lector de chip.
pasan todas las pruebas, a continuación, se pasa el criterio de • Introduzca el número PIN VISA.
aceptación. Si se pasan todas las pruebas de aceptación de • Confirmar fue aceptado el pago.
todos los criterios de aceptación de las historias de usuario, Pasando por estos pasos verifica el criterio de
entonces el historia de usuario se considera probado con éxito. 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 •Proporcionar contexto para desarrolladores mostrando que otra sencilla
usuario. funcionalidad es mejor implementarse antes del trabajo más complejo.
•Dar al Product Backlog una sensación visual de •Proporcionar una visión integrada del producto al no permitir que se centren en
seguimiento. una sola categoría, haciendo hincapié en las múltiples funcionalidades (o categorías)
•Dar perspectiva sobre cómo las historias de de la mayoría de los productos.
usuario pueden relacionarse entre sí. •Dar una mejor comprensión de cómo el producto va a desarrollar y encajar sobre
•Ayudar a identificar lo que podría faltar en cada etapas, es posible ver cómo un producto evolucionará fila por fila, lo que podría
categorí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 Historias de los usuarios Una buena historia de Historias de los usuarios
factible cuando puede ser deben ser trazables, lo que usuario es manejable, lo deben ser simples, lo que
implementada de manera significa que cada que significa que es significa que deben
realista, cuando se tienen requerimiento en una idealmente independiente mantenerse minimalista.
en cuenta las limitaciones historia de usuario se debe de otras historias de Una buena historia de
del producto. Esto incluye ser capaz de realizarle un usuario y se puede usuario se centra sólo en
la tecnología, las seguimiento a lo largo del cambiar sin un impacto la función que será
herramientas, los recursos proyecto. excesivo en otras historias implementada; que no
y el personal disponible, Una técnica en la que los de usuario, esto no hace referencia a la forma
así como el presupuesto y identificadores únicos son siempre es realista por lo en que se llevará a cabo.
el calendario. asignados a cada que la agrupación o la Detalles de diseño
requerimiento se utiliza a vinculación de historias de innecesarios también no
menudo para facilitar el usuario a menudo ayuda a se incluyen en las buenas
seguimiento. Los mantenerlos manejables. historias de usuario. De
identificadores únicos hecho, una buena historia
pueden ser tan simples de usuario debe ser
como números independiente de la
secuenciales. 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!

También podría gustarte