Especificaciones y Requerimientos v2

Los requisitos no funcionales son aquellas propiedades que deben tener, como
fiabilidad, capacidad de almacenamiento, tiempo de respuesta, etc.
Generalmente surgen de necesidades del usuario que políticas tienen que ver con
restricciones de presupuesto, la interoperabilidad con otros sistemas, factores
externos, regulaciones, privacidad, seguridad, etc.
Requerimientos en Scrum y Estimación de tiempos

Dentro de las Metodologías Ágiles se Suelen utilizar las Historias de Usuario
( User Stories ) como Herramienta para definir los Requerimientos del Sistema.
Estas son descripciones o especificaciones de una función, validadas por un usuario
o cliente del sistema.
Generalmente las historias se escriben en un lenguaje que el usuario pueda entender
y que refleje una descripción sintetizada de lo que este desea. En lo posible se
debe tratar de eliminar ambigüedades y malas interpretaciones.
Escribir las historias de usuario con este formato tiene ciertas ventajas:
● Primera persona: Invita a quien la lee a ponerse en el lugar del usuario.

● Priorización: Ayuda al propietario del producto a priorizar y visualizar
mejor cuál es la función, quién se beneficia y cuál es el valor.
● Propósito: la presencia del propósito de una función brinda al equipo la
posibilidad de plantear alternativas que cumplan con el mismo objetivo en caso de
que el costo de la función sea demasiado alto o su construcción no sea viable.
Podemos redactar la historia de usuario del siguiente ejemplo: “Daniel llegó hoy a
Neuquén pero está perdido en su automóvil y dio vueltas por horas. Quiere llegar al
museo provincial de bellas artes “Museo Nacional de Bellas Artes de Neuquén”. En su
celular deberá buscar cómo llegar si la calle es Mitre y Santa Cruz. ”Utilizando la
estructura propuesta de la siguiente forma: Como conductor quiero buscar un
destino a partir de una calle y altura para poder llegar al lugar deseado .
Temas, Épicas e Historias

Durante el proceso de análisis de historias de requerimientos se suele agrupar a
las últimas de usuario en épicas ya su vez, estas últimas están relacionadas con un
tema en particular.
Método INVEST
Este método, desarrollado por Bill Wake en 2003, permite asegurar la calidad de la
escritura de las historias de usuario. Para esto debe cumplir con las siguientes
características:
● Independiente: Cada historia de usuario puede ser planificada e

implementada en cualquier orden. No depende unas de otras, si esto ocurre se deben
dividir o combinar.
● Negociable : Las historias deben ser negociables y sus detalles serán

acordados por el cliente / usuario y el equipo durante la fase de «conversación».
● Valiosa: Una historia de usuario tiene que ser valiosa para el cliente o el
usuario.
● Estimable: Una buena historia de usuario debe ser estimada con la precisión
suficiente para ayudar al cliente o usuario a priorizar y planificar su
implementación. Si no podemos estimarla debemos incidir en la fase de conversación
o dividirla.
● Pequeña ( Small ): Pequeñas. Solemos hacerlas de tal modo que ocupen como
máximo un sprint.
● Comprobable ( Testable ): La historia de usuario debe poderse probar (Hemos
trabajado con anterioridad en la fase "confirmación" de la historia de usuario.
Tanto el usuario como el equipo de desarrollo tienen que poder probarla para saber
cuándo esta finalizada.
Método SMART
Cuando se descomponen las historias de usuario en tareas, se puede utilizar el
método SMART, un método que sirve para evaluar si las tareas están correctamente
definidas. SMART es un acrónimo (en inglés) de las siguientes características:
● Específico: Una tarea debe ser lo suficientemente específica para que todos
puedan entenderla.
● Medible: ¿Hace lo que se pretende? Es el equipo quien debe ponerse de
acuerdo sobre lo que esto significa.
● Alcanzable: ¿Es razonable la meta? Consejo: Es bueno establecer metas que
representen un desafío, pero puede ser contraproducente no alcanzarlas.
● Relevante: Cada tarea debe ser relevante, contribuyendo a la historia en
cuestión.
● A tiempo ( Time-Boxed ): Una tarea debe estar limitada a una duración
específica. No necesariamente debe ser una estimación formal en horas o días, pero
debe haber una expectativa para que la gente sepa cuándo debe ayudar.
Las 3 C de las Historias de Usuario

Una historia de usuario está compuesta de tres elementos que son fundamentales. La
trivial es la primera y la Tarjeta ( Card ), es Donde SE ESCRIBE La historia de
Manera Clara y con la ambigüedad mínima. El segundo componente es la Conversación ,
es importante debatir y validar con el cliente y el equipo de desarrollo, por lo
general, esto se realiza en la reunión de planificación. Y finalmente la
Confirmación , es importante confirmar que todos los involucrados han comprendido
los requisitos.
Puntos de historia
“El trabajo necesario para realizar un requisito o una historia de usuario no se
puede prever de forma absoluta porque rara vez son realidades de una solución
única. En el caso de que se pudiera, por otra parte, la complejidad de la medición
haría una métrica demasiado pesada para la gestión ágil.
No resulta posible estimar con precisión la cantidad de trabajo que hay en un

requisito. En consecuencia, tampoco se puede saber con antelación cuánto tiempo
exigirá, porque a la incertidumbre del trabajo se suman las inherentes al tiempo:
no se puede estimar la cantidad o la calidad del trabajo que realiza una «persona
media» por unidad de tiempo, porque son muy grandes las diferencias de unas
personas a otras. Es más: la misma tarea realizada por la misma persona requerirá
diferentes tiempos según las diferentes circunstancias.
Por todas estas razones, al estimar de forma ágil, se prefiere emplear unidades
relativas. En gestión ágil se suelen emplear «puntos» como unidad de trabajo,
utilizando denominaciones como «puntos de historia». Cada organización, según sus
circunstancias y su criterio, institucionaliza su métrica de trabajo, su «punto».
Es el tamaño relativo de tareas que se suele emplear. Es importante que el
significado y la forma de aplicar la métrica sea siempre la misma en las mediciones
de la organización, y que sea conocida por todos. El tipo de «punto» depende de la
organización. En un equipo de programación el punto puede ser equivalente a
preparar una pantalla de inicio de sesión; para un equipo de diseño gráfico, la
maquetación de un tríptico.
El «punto» ayuda, por un lado, a dimensionar la estimación de una tarea

comparándola con una ya conocida, y por otro lado, a contrastar la dificultad que
la tarea presenta para cada miembro del equipo según sus especialidades. Un ejemplo
para ilustrar esto último podría ser el esfuerzo que cuesta freír un huevo. Si se
estima cuántos «huevos fritos» costaría planchar una camisa, la respuesta
dependiente de la persona. Alguien puede ser muy habilidoso friendo huevos, pero
muy torpe para planchar camisas, y estimará que eso le costaría «8 huevos fritos»;
es decir, «8 puntos». Alguien muy acostumbrado a las tareas domésticas, en cambio,
podría estimar la tarea en «un punto» o «un huevo frito».
Ambos tienen razón: la cuestión es que la persona que estime sea la que va a
realizar la tarea. Los «puntos de historia» suelen ser una unidad relativa o
abstracta basada en algo con lo que el equipo esté muy familiarizado.
Por último, con esto se puede estimar la velocidad: en scrum, ésta es igual a la
cantidad de trabajo realizado por el equipo en un sprint. Así, por ejemplo, una
velocidad de 150 puntos indica que el equipo realiza 150 puntos de trabajo en cada
sprint.
No obstante, al salir del marco estándar de scrum podemos encontrar sprints de

diferentes duraciones. Cuando esto sucede, se puede expresar la velocidad en
unidades de tiempo en lugar de por sprint. Es decir: «la velocidad media del equipo
es de x puntos por semana». ”
Los puntos de historia representan un valor que sólo será relevante para el equipo
de scrum, y que se usará para estimar el tamaño de una tarea (también llamada ítem,
en inglés) en el backlog. Permite al equipo determinar qué tareas pueden realizar
en un sprint. El product owner (“propietario del producto” en su traducción
literal) podrá ver, por los puntos de la historia, qué tareas fueron relativamente
complicadas de hacer por el equipo. Los puntos dan una idea del tamaño y el
esfuerzo que se necesita para las tareas realizadas.
Para empezar con los puntos de la historia, el equipo debe primero definir una
historia de referencia (o pivote) con la que después podrá comparar todas las
historias. Se recomienda elegir una historia de usuario más o menos compleja, que
incluya tantas disciplinas del equipo como sea posible. A esta historia le daremos
un puntaje, posiblemente 5 u 8. Luego, se utiliza el pivote durante los
perfeccionamientos del sprint backlog para determinar si otra historia de usuario
es más pequeña o más grande, y qué valor puede darle.

Especificaciones y Requerimientos v2

Cargado por

Copyright:

Formatos disponibles

Especificaciones y Requerimientos v2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Especificaciones y Requerimientos v2

Cargado por

Copyright:

Formatos disponibles

Los requisitos no funcionales son aquellas propiedades que deben tener, como

fiabilidad, capacidad de almacenamiento, tiempo de respuesta, etc.

Requerimientos en Scrum y Estimación de tiempos

● Primera persona: Invita a quien la lee a ponerse en el lugar del usuario.

Temas, Épicas e Historias

● Independiente: Cada historia de usuario puede ser planificada e

● Negociable : Las historias deben ser negociables y sus detalles serán

Las 3 C de las Historias de Usuario

No resulta posible estimar con precisión la cantidad de trabajo que hay en un

El «punto» ayuda, por un lado, a dimensionar la estimación de una tarea

No obstante, al salir del marco estándar de scrum podemos encontrar sprints de

También podría gustarte