> For the complete documentation index, see [llms.txt](https://elguerre.gitbook.io/de0an/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://elguerre.gitbook.io/de0an/capitulo-3-no-comiences-todavia.-primero-el-prototipo/necesidades-o-requerimientos.md).

# Necesidades o requerimientos

Como ya hemos comentado, una de las primeras dudas que tenemos que resolver antes de comenzar a desarrollar una aplicación, son los requisitos. Definiremos a continuación cuáles son los principales que necesitará **Task\[in]:**

1. Proyectos
   1. El usuario podrá obtener un listado de proyectos que podrá editar o borrar y crear nuevos.
   2. El usuario podrá cambiar o categorizar los proyectos: Predeterminado, Personal, Trabajo y Otros.
   3. El usuario podrá personalizar la imagen de un proyecto accediendo a la librería del dispositivo.
2. Tareas
   1. Para cada proyecto, el usuario podrá obtener un listado de tareas que podrá editar o borrar y crear nuevas.
   2. Cada tarea se podrá completar con uno o varios *Pomodoros* en función de un esfuerzo estimado.
   3. Cada tarea podrá componerse, a su vez, de varios elementos en forma de lista de comprobación o *checklist*.
3. Pomodoros[¹](/de0an/capitulo-3-no-comiences-todavia.-primero-el-prototipo/que-hemos-aprendido.md#notas)
   1. Para cada tarea el usuario podrá obtener el listado de Pomodoros. Podrá cancelarlos y visualizar su estado.
   2. Para cada tarea el usuario podrá crear Pomodoros a partir de un esfuerzo estimado basado en la sucesión de Fibonacci[²](/de0an/capitulo-3-no-comiences-todavia.-primero-el-prototipo/que-hemos-aprendido.md#notas).
4. Checklist (o listado de sub-tareas)
   1. Para cada tarea el usuario consultará el listado elementos de la checklist, desde donde podrá añadir, modificar o eliminar los mismos.

Cada uno de los requisitos anteriores podrá descomponerse en cuantas tareas sean necesarias para su resolución y, de la misma forma, podrá contener *Bugs* o *Impedimentos* que irán apareciendo a lo largo del ciclo de vida de la aplicación.

{% hint style="info" %}
**Nota**: Se aconseja indicar en la descripción de cada requisito todo el detalle posible para dejar claro el alcance del mismo. Incluir asunciones también puede ayudar a concretar.
{% endhint %}

No basta con escribir los requisitos en papel, si vamos a seguir las buenas prácticas, entonces es el momento de utilizar VSTS para digitalizarlos. ¿Cómo lo hacemos? Es fácil:

1. Acceder a VSTS según vimos en el capítulo 1, a través de la url: (ej.: `http://juanluisguerrero.visualstudio.com`).
2. Seleccionar el proyecto Task\[in]
3. Navegar al listado de requisitos (o *Backlog*). En la pantalla de bienvenida, seleccionar “Add work to your board” o bien “Backlog”.

![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-8e6cfbd9c3a4467dcf54bb0af17e2846ee9fddee%2Fimage1.png?alt=media)

**Figura 01.- Pantalla de bienvenida del proyecto Task\[in] en VSTS**

4. Introducir todos los requisitos o Product Backlog Items (**PBIs**).

![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-5e75eef1ae9775f20a7d7184362ffeacbcc2fa69%2Fimage2.png?alt=media)

**Figura 02.- Creando el Backlog**

5. Tras completar la introducción de todos ellos, tendremos algo similar a la siguiente imagen:

![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-7266a497be8ceb375516d76e362fd4ed4cd3cdac%2Fimage3.png?alt=media)

**Figura 03.- Listado de requisitos o Product Backlog ítems (PBIs)**

6. A partir de este instante asignaremos las prioridades, esfuerzo, valor de negocio y demás datos para cada elemento. Incluiremos también el máximo detalle tal y como hemos comentado anteriormente y remarcaremos el alcance del requisito incluyendo los criterios de aceptación.

![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-b4693e3112481363827beeeb063b7eac999c173a%2Fimage4.png?alt=media)

**Figura 04.- Edición de un requisito o PBI**

7. Introduciremos también la Definición de Hecho (o *Definition of Done*) que como su propio nombre indica, refleja con claridad cuando se considera que los requisitos o **PBIs se han finalizado completamente, es decir, al 100%**. Esta definición es la misma para todos los requisitos y aplica a todos ellos por igual. La encontraremos en la pestaña “Definition of Done” de cada requisito.

![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-c25b62b94f8de7a230fe3539ded7a58396fab755%2Fimage5.png?alt=media)

**Figura 05.- Edición de la Definición de Hecho del PBI anterior**

8. A cada requisito le asociaremos una historia de usuario (o *User Story*), que no es ni más ni menos que la representación o guion gráfico del flujo que sigue el usuario para alcanzar el requisito. Utilizaremos para ello la opción de menú “Start storyboarding” de VSTS tal y como podemos ver en la siguiente figura.

![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-002bf1a7aef1243f13f074baccd59b1d8d7916af%2Fimage6.png?alt=media)

**Figura 06.- Añadiendo una historia de usuario a un requisito utilizando VSTS**

Podemos conseguir también esta asociación, desde el menú “Storyboarding” en PowerPoint.

![](https://240651724-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FfrvHBNivOTy0fVKROgzo%2Fuploads%2Fgit-blob-d01dde93282c7519b3368565afce4b347570cc66%2Fimage7.png?alt=media)

**Figura 07.- Menú Storyboarding de PowerPoint**

9. Y, por último, a cada requisito le asignamos un propietario, quien creará las tareas necesarias para completarlo y asignará éstas a cada miembro del equipo de trabajo.

Esta manera de proceder se corresponde con el marco de trabajo (o *framework*) Scrum[³](/de0an/capitulo-3-no-comiences-todavia.-primero-el-prototipo/que-hemos-aprendido.md#notas). No es objetivo de este libro abordar en profundidad este tema, si bien, se recomienda leer el libro gratuito: <http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Spanish.pdf>.

Para profundizar más en la creación y organización del Backlog, cómo implementar Scrum en VSTS, el uso de *Kanban* (o *Board*), etc., visitar la página: <https://www.visualstudio.com/es-es/docs/work/overview>.

Siguiendo este marco de trabajo y con estos requisitos en mente, comenzaremos a dar forma a nuestra aplicación aportándole: estilos, colores, tipografía, estructura de la información, navegación entre páginas, etc.

Aunque este proceso puede parecer muy sencillo, requiere de un gran análisis y creatividad. Para hacer que todo sea posible, nos centraremos en el Lenguaje de Diseño de Microsoft.