Merge pull request #63 from ucudal/task/reorganize-requirements

Task: Reorganize requirements

.markdownlint.json

@@ -6,6 +6,9 @@
     "tables": false
   },
   "MD033": false,
+  "MD024": {
+    "siblings_only": true
+  },
   "MD041": false,
   "MD049": {
     "style": "asterisk"

1_Entregable_proyecto/1_1_1_Impulsores_del_proyecto.md

@@ -0,0 +1,157 @@
+# 1 Entregable del proyecto
+
+## 1.1 Requisitos
+
+### 1.1.1 Impulsores del proyecto
+
+En esta primera parte deben dejar en claro que están familiarizados con el
+propósito del proyecto, su oportunidad de negocio, motivaciones y objetivos, así
+como también su proyección y cualquier entidad interesada en el mismo.
+
+## Propósito del proyecto
+
+<!-- SECCIÓN: Declaración del problema -->
+<!-- TAG: Requerido -->
+<img alt="REQUERIDO" src="https://img.shields.io/badge/REQUERIDO-FF4D4D" />
+
+Sin entrar en detalles, describir el problema que este proyecto intenta
+resolver. Opcionalmente se puede utilizar el siguiente formato:
+
+<table>
+  <tr><td>El problema</td><td><i>(descripción del problema)</i></td></tr>
+  <!-- TODO Agregar definición y link para 'stakeholders' -->
+  <tr><td>Afecta a</td><td><i>(stakeholders afectados)</i></td></tr>
+  <tr><td>Cuyo impacto es</td><td><i>(¿cuál es el impacto del problema?)</i></td></tr>
+  <tr><td>Una solución exitosa debe tener</td><td><i>(listar algunos beneficios
+  clave de una solución exitosa)</i></td></tr>
+</table>
+
+<!-- SECCIÓN: Declaración del posicionamiento del producto -->
+Dar un resumen general que indique, a alto nivel y sin entrar en detalles, las
+características del producto a desarrollar. Algunas cosas a mencionar:
+
+* Organización cliente (opcional, si ya se mencionó antes)
+
+* Categoría del producto y opcionalmente nombre, en caso de tenerlo definido.
+  **Preguntas disparadoras**: *¿Qué es el producto que voy a desarrollar? ¿Cómo
+  se llama?*
+
+* Beneficios del producto
+
+* Productos alternativos. Estas alternativas compiten con la realización de este
+  proyecto y pueden incluir comprar un producto de la competencia, construir una
+  solución internamente o simplemente mantener el status quo. **Pregunta
+  disparadora**: *¿Qué otros productos similares existen actualmente?*
+
+* Diferenciación del producto en comparación con las alternativas. **Preguntas
+  disparadoras**: *¿Qué tiene de diferente mi producto a desarrollar en
+  comparación con las alternativas mencionadas? ¿Por qué el cliente no utiliza
+  las alternativas?*
+
+<!-- SECCIÓN: Oportunidad de negocio -->
+Describir brevemente la oportunidad de negocio que el cliente trata de alcanzar
+con este proyecto, esto es: explicar por qué el negocio del cliente se beneficia
+de este proyecto y cómo.
+
+<!-- SECCIÓN: Estadísticas del mercado o usuarios -->
+Resumir los datos demográficos clave que motivan las decisiones del producto.
+**Algunas preguntas disparadoras**: *¿Cuántos usuarios tendrá el producto? ¿Cómo
+se estima que crecerá el número de usuarios? ¿Cuánto dinero gasta el cliente
+tratando de satisfacer por otros medios las necesidades que el producto podrá
+cubrir?*
+
+<!-- SECCIÓN: Objetivos del proyecto -->
+<!-- TODO Agregar definiciones y links para 'objetivos', 'propósito', 'beneficio'
+y 'métricas del beneficio' -->
+Mencionar a alto nivel los objetivos del proyecto. Para ello, describir el
+propósito, beneficio y métricas del beneficio para cada objetivo. Se puede usar
+el siguiente formato:
+
+| Objetivo              | Propósito                | Beneficio                | Métrica del beneficio          |
+| --------------------- | ------------------------ | ------------------------ | ------------------------------ |
+| *Título del objetivo* | *Propósito del objetivo* | *Beneficio del objetivo* | *Cuantificación del beneficio* |
+| ...                   | ...                      | ...                      | ...                            |
+
+## Los interesados o *stakeholders*
+
+<!-- SECCIÓN: Cliente del proyecto -->
+<!-- TAG: Requerido -->
+<img alt="REQUERIDO" src="https://img.shields.io/badge/REQUERIDO-FF4D4D" />
+
+<!-- TODO Agregar definición y link para 'cliente' -->
+Mencionar el cliente o clientes del proyecto. Limitarse a mencionar tres como
+máximo. Para cada uno, mencionar su rol en la organización, rol en el proyecto,
+perfil técnico, criterio de éxito (cómo el cliente define el éxito del proyecto
+o factores clave para que el cliente considere al proyecto exitoso) y otros
+comentarios sobre el cliente.
+
+<!-- SECCIÓN: Usuarios -->
+Describir a los usuarios del sistema. Se puede usar el siguiente formato como
+guía:
+
+<table>
+  <tr><td>Descripción</td><td><i>Descripción breve del usuario y la relación que
+  tendrá con el sistema.</i></td></tr>
+  <!-- TODO Agregar definición y link para 'stakeholders' -->
+  <tr><td>Representado por</td><td><i>Stakeholders que representan en el proyecto
+  a este tipo de usuario. Por ejemplo, el usuario “telefonista” podría estar
+  representado por el stakeholder “Encargado del Call Center”</i></td></tr>
+  <tr><td>Rol en la organización</td><td><i>Descripción del rol que desempeña en
+  la organización cliente.</i></td></tr>
+  <tr><td>Rol en el sistema</td><td><i>Descripción del rol que tendrá con respecto
+  a la operación del sistema. Por ejemplo: “este usuario ingresará los datos de
+  ventas”.</i></td></tr>
+  <tr><td>Perfil técnico</td><td><i>Describir el nivel técnico a efectos del uso
+  de un sistema de software. Por ejemplo: usuario común, técnico avanzado, experto
+  del negocio, experto en tecnologías.</i></td></tr>
+  <tr><td>Criterio de éxito</td><td><i>¿Cómo el usuario define el éxito del
+  proyecto? ¿Qué factores determinan el éxito del proyecto según el usuario?</i></td></tr>
+  <tr><td>Comentarios</td><td><i>Comentarios sobre el usuario.</i></td></tr>
+</table>
+
+<!-- SECCIÓN: Otros interesados -->
+Mencionar otras personas u organizaciones interesadas en el proyecto o afectadas
+por él. Estos interesados pueden formar parte de la organización cliente o
+trabajar para ella y sus comentarios pueden ser valiosos para el proyecto, por
+ejemplo: patrocinadores, expertos del dominio, usuarios del sistema actual,
+expertos en legislación, diseñadores, usuarios encargados del mantenimiento del
+sistema, encargados del servicio técnico, etcétera. Para cada uno de ellos,
+detallar: rol en el proyecto, rol en la organización, aporte al proyecto, grado
+de involucración en el proyecto y nivel de influencia en el proyecto.
+
+<!-- SECCIÓN: Identificación de necesidades clave -->
+Listar los problemas clave junto con las soluciones existentes, de acuerdo a la
+percepción de los interesados. Aclarar los siguientes elementos de cada
+problema:
+
+* ¿Cuáles son las razones para este problema?
+
+* ¿De qué manera se lo soluciona ahora?
+
+* ¿Qué soluciones desea el interesado?
+
+Se puede usar el siguiente formato para cada necesidad:
+
+<table>
+  <tr><td>Descripción</td><td><i>Breve descripción de la necesidad y sus motivos.</i></td></tr>
+  <tr><td>Prioridad</td><td><i>¿Qué nivel de prioridad tiene esta necesidad?</i></td></tr>
+  <tr><td>Concierne a</td><td><i>¿A quién concierne esta necesidad?</i></td></tr>
+  <tr><td>Solución actual</td><td><i>¿Cuál es la solución actual para esta necesidad?</i></td></tr>
+  <tr><td>Solución propuesta</td><td><i>¿Qué solución propone el sistema ante esta
+  necesidad?</i></td></tr>
+</table>
+
+<!-- SECCIÓN: Comprador o consumidor del producto -->
+<!-- TAG: Según proyecto -->
+<img
+  alt="SEGÚN PROYECTO"
+  src="https://img.shields.io/badge/SEG%C3%9AN%20PROYECTO-FFD700"
+/>
+
+Dependiendo de la naturaleza del producto a desarrollar, puede existir un
+comprador o consumidor de ese producto. En caso de que su proyecto involucre
+desarrollar un producto que luego será adquirido por un tercero, mencionar el
+arquetipo del comprador o consumidor del producto. Por ejemplo, si el producto a
+desarrollar fuera una aplicación de gestión de seguimiento de horas de
+empleados, el consumidor podría ser cualquier empresa interesada en hacer un
+seguimiento de horas de sus empleados.

1_Entregable_proyecto/1_1_2_Restricciones_del_proyecto.md

@@ -0,0 +1,86 @@
+# 1 Entregable del proyecto
+
+## 1.1 Requisitos
+
+### 1.1.2 Restricciones del proyecto
+
+En esta segunda parte deben mencionar todas las restricciones que afecten al
+proyecto, así como también asunciones que hagan acerca de él y que su
+cumplimiento —o, incumplimiento— puedan afectarlo. Además, deben definir una
+convención de denominaciones y términos que serán utilizados a lo largo del
+documento de forma consistente.
+
+## Restricciones obligatorias
+
+<!-- SECCIÓN: Restricciones de diseño y tecnologías -->
+<!-- TAG: Requerido -->
+<img alt="REQUERIDO" src="https://img.shields.io/badge/REQUERIDO-FF4D4D" />
+
+Cada una de las restricciones mencionadas en esta parte debe usar la [plantilla
+de requerimiento atómico](../3_Plantillas/3_1_Requerimiento_atomico.md).
+
+Mencionar las restricciones relacionadas con el diseño de la solución. *(¿La
+solución deberá ser una aplicación web? ¿deberá ser una aplicación mobile?
+¿deberá seguir un patrón de arquitectura de software en específico?)*
+
+En caso de existir restricciones sobre las tecnologías a utilizar para el
+desarrollo de la solución, detallarlas mencionando —en caso de ser pertinente—
+la versión de las mismas.
+
+<!-- SECCIÓN: Restricciones de entorno de instalación -->
+Mencionar aquellas restricciones relacionadas al entorno de instalación de la
+solución. Estas pueden ser restricciones en cuanto al lugar físico o virtual en
+el cual la solución final deberá ser instalada. Suele ser conveniente utilizar
+un diagrama para explicar las interacciones del sistema con el entorno y otros
+sistemas con los que la solución deba interactuar.
+
+<!-- SECCIÓN: Restricciones de calendario -->
+Mencionar las restricciones temporales o *deadlines* del proyecto. En caso de
+existir alguna ventana temporal de oportunidad, mencionarla también. Para cada
+una de estas restricciones de calendario, detallar el momento o fecha
+claramente, explicar el grado de importancia de la restricción y por qué es
+importante. Además, explicar las consecuencias de no cumplir con la restricción.
+
+<!-- SECCIÓN: Restricciones de utilización de software externo -->
+<!-- TAG: Según proyecto -->
+<img
+  alt="SEGÚN PROYECTO"
+  src="https://img.shields.io/badge/SEG%C3%9AN%20PROYECTO-FFD700"
+/>
+
+Puede ser el caso de que para su proyecto exista la obligación de que la
+solución se integre con con un software externo específico, en caso de ser así,
+detallarlo.
+
+<!-- SECCIÓN: Restricciones organizacionales -->
+Opcionalmente, la organización o empresa cliente puede demandar ciertas
+restricciones provenientes de sus políticas. En caso de aplicar, detallar estas
+restricciones.
+
+<!-- SECCIÓN: Restricciones de presupuesto -->
+La organización o empresa cliente puede habilitar ciertos recursos con
+determinado límite —incluidos recursos monetarios—, y como los requerimientos no
+deben exceder el presupuesto, esta restricción determina qué requerimientos son
+incluidos en el producto. En caso de que el cliente establezca un presupuesto
+(expresado en términos monetarios o recursos disponibles), detallarlo.
+
+## Convenciones de denominación y términos
+
+<!-- SECCIÓN: Glosario -->
+<!-- TAG: Requerido -->
+<img alt="REQUERIDO" src="https://img.shields.io/badge/REQUERIDO-FF4D4D" />
+
+Explicar todas las abreviaturas, términos y acrónimos particulares empleados en
+el contexto del proyecto y del problema que son utilizados en el documento.
+
+## Hechos relevantes y asunciones
+
+<!-- SECCIÓN: Asunciones y dependencias -->
+<!-- TAG: Requerido -->
+<img alt="REQUERIDO" src="https://img.shields.io/badge/REQUERIDO-FF4D4D" />
+
+Listar los asunciones que, si fueran cambiadas, cambiarían las capacidades del
+producto tal y como están descritas en este documento. Por ejemplo, una asunción
+puede ser que un sistema operativo específico estará disponible para el
+producto, de tal forma que si el sistema operativo no está disponible, el
+documento deberá ajustarse.