+
+Sin entrar en detalles, describir el problema que este proyecto intenta
+resolver. Opcionalmente se puede utilizar el siguiente formato:
+
+| El problema | (descripción del problema) |
| Afecta a | (stakeholders afectados) |
| Cuyo impacto es | (¿cuál es el impacto del problema?) |
| Una solución exitosa debe tener | (listar algunos beneficios + clave de una solución exitosa) |
+
+
+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.
+
+
+Describir a los usuarios del sistema. Se puede usar el siguiente formato como
+guía:
+
+| Descripción | Descripción breve del usuario y la relación que + tendrá con el sistema. |
| Representado por | 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” |
| Rol en la organización | Descripción del rol que desempeña en + la organización cliente. |
| Rol en el sistema | Descripción del rol que tendrá con respecto + a la operación del sistema. Por ejemplo: “este usuario ingresará los datos de + ventas”. |
| Perfil técnico | 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. |
| Criterio de éxito | ¿Cómo el usuario define el éxito del + proyecto? ¿Qué factores determinan el éxito del proyecto según el usuario? |
| Comentarios | Comentarios sobre el usuario. |
| Descripción | Breve descripción de la necesidad y sus motivos. |
| Prioridad | ¿Qué nivel de prioridad tiene esta necesidad? |
| Concierne a | ¿A quién concierne esta necesidad? |
| Solución actual | ¿Cuál es la solución actual para esta necesidad? |
| Solución propuesta | ¿Qué solución propone el sistema ante esta + necesidad? |
+
+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.
diff --git a/1_Entregable_proyecto/1_1_2_Restricciones_del_proyecto.md b/1_Entregable_proyecto/1_1_2_Restricciones_del_proyecto.md
new file mode 100644
index 0000000..ae248d6
--- /dev/null
+++ b/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
+
+
+
+
+
+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.
+
+
+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.
+
+
+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.
+
+
+
+
+
+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.
+
+
+Opcionalmente, la organización o empresa cliente puede demandar ciertas
+restricciones provenientes de sus políticas. En caso de aplicar, detallar estas
+restricciones.
+
+
+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
+
+
+
+
+
+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
+
+
+
+
+
+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.
diff --git a/1_Entregable_proyecto/1_1_3_Requerimientos_funcionales.md b/1_Entregable_proyecto/1_1_3_Requerimientos_funcionales.md
new file mode 100644
index 0000000..9f5fcd5
--- /dev/null
+++ b/1_Entregable_proyecto/1_1_3_Requerimientos_funcionales.md
@@ -0,0 +1,152 @@
+# 1 Entregable del proyecto
+
+## 1.1 Requisitos
+
+### 1.1.3 Requerimientos funcionales
+
+En esta tercera parte deben definir el [área de
+trabajo](/4_Conceptos/4_Trabajo_y_area_de_trabajo.md), alcance del proyecto y
+sus requerimientos funcionales.
+
+## Área de trabajo
+
+
+
+
+
+Utilizando un [diagrama
+BPMN](../2_Tecnicas_y_herramientas/2_4_4_Diagramas_BPMN.md), denotar los
+procesos de negocio pertinentes que existen actualmente y que pueden ser
+reemplazados o cambiados por la solución a desarrollar.
+
+
+A alto nivel y mediante un [diagrama de
+contexto](../2_Tecnicas_y_herramientas/2_1_2_Diagramas_de_contexto.md), explicar
+las interacciones de la solución con sus sistemas
+[adyacentes](/4_Conceptos/4_Sistema_adyacente.md) —otras personas,
+organizaciones, hardware y software— y el input/output de estas interacciones.
+
+
+A alto nivel, listar todos los [eventos del
+negocio](/4_Conceptos/4_Evento_del_negocio.md) a los que el trabajo a
+desarrollar responde (es decir, [casos de uso del
+negocio](../4_Conceptos/4_Caso_de_uso_del_negocio.md)), indicando: nombre del
+evento del negocio, entrada (input) o información proveniente de la entidad
+adyacente, salida (output) a la entidad adyacente y una breve descripción del
+caso de uso del negocio. Se puede utilizar el siguiente formato:
+
+| Evento del negocio | Input y output | Descripción del caso de uso del negocio |
+| -------------------------------- | ---------------------------------------------- | ------------------------------------------------- |
+| *(Nombre del evento del negocio)* | *(Input y output del caso de uso del negocio)* | *(Breve descripción del caso de uso del negocio)* |
+
+
+Detallar el paso a paso de cómo cada caso de uso del negocio identificado
+anteriormente responde al evento del negocio correspondiente. Esto se puede
+realizar mediante diagramas de actividad, escenarios de caso de uso del negocio,
+diagramas de flujo, diagramas de secuencia o mapas mentales.
+
+## Modelo de datos organizacionales y diccionario de datos
+
+
+
+
+
+> [!NOTE]
+> Cuando estés especificando el modelo de datos organizacionales y el
+> diccionario de datos, asegúrate de ser consistente con la subsección de
+> [convenciones de denominación y
+> términos](./1_1_2_Restricciones_del_proyecto.md#convenciones-de-denominación-y-términos)
+> —es una buena idea que las entidades del dominio estén definidas en esa
+> sección—. A su vez, es una buena práctica el mantener un lenguaje ubicuo a lo
+> largo y ancho del proyecto[^1].
+
+Mediante un [diagrama de clases
+UML](../2_Tecnicas_y_herramientas/2_3_1_Diagramas_de_clases_UML.md), un [modelo
+entidad-relación](/2_Tecnicas_y_herramientas/2_3_2_Modelos_de_entidad_relacion.md)
+o cualquier otro diagrama de datos, especificar todas las entidades o clases
+relevantes al contexto del trabajo. Lo interesante aquí es mostrar todas las
+entidades en cuestión y sus atributos o propiedades, además de mostrar cómo las
+entidades se relacionan entre sí (para ello es importante indicar la
+cardinalidad en las relaciones).
+
+
+Definir el contenido o formato de los siguientes items vistos en el modelo de
+datos organizacionales:
+
+* Entidades o clases
+* Atributos
+* Relaciones entre las entidades o clases
+* Entradas y salidas de los modelos
+* Datos dentro de las entradas y salidas
+
+Se puede utilizar el siguiente formato:
+
+| Nombre | Contenido | Tipo |
+|--------|-----------|------|
+| *Nombre* | *Contenido de la entidad/clase o formato del atributo* | *Clase/Relación/Atributo* |
+
+> [!NOTE]
+> En la columna ***Contenido***, nombrar los atributos de la entidad, y si la
+> entrada pertenece a un atributo en vez de a una entidad, mencionar el formato
+> del atributo.
+
+Tanto el diccionario de datos como el modelo de datos organizacionales se irán
+ampliando junto con el desarrollo de la solución, esto es: a medida que se vayan
+haciendo ajustes o adiciones de clases/atributos/datos en el desarrollo de la
+solución, reflejar estos cambios en el diccionario de datos y el modelo de datos
+organizacionales.
+
+Los términos utilizados en el diccionario de datos son los términos que se han
+de usar al definir requerimientos atómicos detallados.
+
+## Alcance del proyecto
+
+
+
+
+
+Mediante un [diagrama de casos de
+uso](/2_Tecnicas_y_herramientas/2_4_2_Diagramas_de_casos_de_uso_UML.md), definir
+los casos de uso del producto. Una tabla con la misma información que los
+diagramas de casos de uso —es decir, nombre de los casos de uso, actores
+participantes, relación de `extends` o `includes` con otros casos de uso— suele
+ser más cómoda cuando la cantidad de casos de uso es mayor a 20.
+
+
+Definir los detalles de cada [caso de uso del
+producto](../4_Conceptos/4_Caso_de_uso_del_producto.md). Esto se puede realizar
+mediante una de las siguientes opciones:
+
+> [!NOTE]
+> El próximo listado está ordenado descendentemente según la formalidad
+> de cada alternativa, esto es: la primer opción es la más formal, la última la
+> menos. De las cinco opciones presentadas, las tres primeras las consideramos
+> formales y las últimas dos informales.
+
+* Un escenario descrito textualmente, paso a paso, incluyendo excepciones y
+ alternativas
+* Un [diagrama de actividades
+ UML](../2_Tecnicas_y_herramientas/2_4_1_Diagramas_de_actividades_UML.md) o un
+ [diagrama de procesos
+ BPMN](/2_Tecnicas_y_herramientas/2_4_4_Diagramas_BPMN.md)
+* Una historia de usuario descrita textualmente
+* Un guión gráfico
+* Un prototipo de baja o alta fidelidad
+
+> [!WARNING]
+> A efectos del entregable del proyecto, deben utilizar **al menos una opción
+> formal**, aunque pueden utilizar de forma adicional opciones informales para
+> profundizar en los casos de uso o aclararlos. Para utilizar únicamente
+> opciones informales, deben contar con la autorización de tu tutor.
+
+## Requerimientos funcionales
+
+
+
+
+
+Detallar los requerimientos funcionales del producto utilizando el [template de
+requerimiento atómico](../3_Plantillas/3_1_Requerimiento_atomico.md) para cada
+uno de ellos. Estos requerimientos emergen de los casos de uso del producto.
+
+[^1]: Evans, E. (2003). Domain-Driven Design. Addison-Wesley Professional.
diff --git a/1_Entregable_proyecto/1_1_4_Requerimientos_no_funcionales.md b/1_Entregable_proyecto/1_1_4_Requerimientos_no_funcionales.md
new file mode 100644
index 0000000..8a6872b
--- /dev/null
+++ b/1_Entregable_proyecto/1_1_4_Requerimientos_no_funcionales.md
@@ -0,0 +1,286 @@
+# 1 Entregable del proyecto
+
+## 1.1 Requisitos
+
+### 1.1.4 Requerimientos no funcionales
+
+En esta cuarta parte deben definir todos los diferentes tipos de requerimientos
+no funcionales que apliquen a su proyecto. Para ello, deben usar la [plantilla
+de requerimiento atómico](/3_Plantillas/3_1_Requerimiento_atomico.md) en cada
+requerimiento.
+
+Tengan en cuenta que no todos los requerimientos no funcionales mencionados aquí
+necesariamente aplican, así que deben ser prudentes y analizar cuáles sí son
+necesarios, así como cuáles no.
+
+## Requerimientos de apariencia
+
+
+
+
+
+No todos los proyectos tratan de un producto que necesita una interfaz de
+usuario, pero en el caso de que su producto a desarrollar sí la necesite,
+detallar los requerimientos asociados a la apariencia del sistema, por ejemplo:
+guías de UX/UI a utilizar —quizá brindadas por el cliente—, marca corporativa de
+la organización cliente, qué colores utilizar, etcétera.
+
+## Requerimientos de usabilidad y humanidad
+
+
+
+
+
+Similarmente a los requerimientos de apariencia, en caso de que el producto a
+desarrollar necesite de algún tipo de interacción con los usuarios finales,
+detallar los requerimientos del cliente en cuanto a la facilidad de uso del
+sistema por parte de estos usuarios finales. Tengan en cuenta que esta facilidad
+es derivada de la habilidad de los previstos usuarios finales y la complejidad
+del producto y sus funcionalidades. Algunas características a tener en cuenta
+pueden ser:
+
+
+
+* Eficiencia de uso: Qué tan rápido o con qué precisión el usuario puede usar el
+ producto.
+* Facilidad de memorización: Qué tanto se espera que el usuario casual memorice
+ en cuanto a usar el producto.
+* Tasa de errores: Qué tantos errores sería aceptable que el usuario cometa.
+ Para algunos productos, es crucial que el usuario cometa muy pocos errores, o
+ en ocasiones, ninguno.
+* Satisfacción general al usar el producto: Para productos que tienen cierta
+ competencia, es esencial que los usuarios se sientan muy satisfechos al usar
+ el producto. De ser el caso, es valioso registrar esto como un requerimiento.
+* Retroalimentación: Qué tanta retroalimentación el usuario necesita para
+ sentirse confiado en cuanto a que el producto está haciendo precisa y
+ correctamente lo que se espera de él. Productos de seguridad o tareas críticas
+ suelen necesitar un alto nivel de retroalimentación.
+
+
+Siguiendo el punto anterior, también detallar las expectativas del cliente en
+cuanto a qué tanto esfuerzo deberán emplear los usuarios finales para poder
+utilizar el sistema de una forma productiva. Algunos sistemas deben ser muy
+fáciles de utilizar y por ende intuitivos, otros se pueden permitir determinada
+curva de aprendizaje debido a la complejidad del problema. La idea aquí es
+cuantificar la cantidad de tiempo o esfuerzo que los usuarios finales necesitan
+para aprender a usar el sistema y que esta cuantificación sea aceptable para el
+cliente. Esta clarificación puede incluir un plan de capacitación para los
+usuarios, e incluso un manual de usuario, por ejemplo: "Los usuarios deberán ser
+capaces de usar el sistema tras una semana de capacitación" o, "Los usuarios
+deberán ser capaces de utilizar el sistema tras leer el manual de usuario".
+
+
+En caso de que sea establecido por el cliente como una necesidad, especificar
+los requerimientos asociados a las preferencias de los usuarios. Estos
+requerimientos indican cómo el sistema puede ser modificado o configurado por
+los usuarios para tener en cuenta sus preferencias y selección de lenguaje
+utilizado por el sistema. En otras culturas, se usan diferentes sistemas de
+unidades —sistema métrico, anglosajón, etcétera—, unidades monetarias, idiomas,
+etcétera.
+
+
+Especificar los requerimientos asociados a la accesibilidad del sistema.
+Dependiendo del problema y el producto, este tipo de requerimientos puede ser
+más necesario.
+
+
+En caso de que usar el producto desarrollado signifique un posible riesgo de
+daño percibido a personas o propiedad dentro del entorno de uso, detallar los
+requerimientos que cuantifican este daño. Estos pueden estar relacionados a
+estándares de seguridad o protección.
+
+## Requerimientos de performance
+
+
+
+
+
+Detallar la cantidad de tiempo disponible para el producto al realizar
+diferentes tareas en términos de latencia y velocidad. Un ejemplo de latencia:
+"El sistema deberá responder a cualquier interacción en un tiempo menor a dos
+segundos". Un ejemplo de velocidad: "El sistema deberá refrescar el estado de
+cuenta cada 5 minutos".
+
+
+Especificar los requerimientos asociados a la precisión de los resultados
+producidos por el producto, por ejemplo: "El sistema deberá mostrar las unidades
+monetarias con una precisión de tres decimales" o, "El sistema deberá calcular
+los grados de temperatura con una precisión de ± 1°C respecto al valor real".
+
+
+
+Definir los requerimientos de confiabilidad y disponibilidad del sistema, esto
+es: ¿qué tanto tiempo deberá estar disponible el sistema? ¿en qué momentos del
+día o qué días ha de estarlo? ¿qué porcentaje de tiempo de actividad deberá
+cumplir? ¿qué tasa de fallos del sistema es aceptable?
+
+
+Indicar los requerimientos de robustez del sistema, esto es: la capacidad del
+sistema de continuar funcionando de forma aceptable bajo condiciones anormales.
+Por ejemplo: "El sistema deberá seguir proveyendo la funcionalidad X al no tener
+conexión a Internet".
+
+
+Especificar la cantidad de volumen de datos o usuarios que el sistema deberá
+soportar. ¿Qué tantos usuarios en simultáneo deberá soportar el sistema? ¿este
+número cambia para determinado momento del día?
+
+
+Detallar aquellos requerimientos relacionados a la escalabilidad del sistema.
+
+
+Especificar los requerimientos que definen la longevidad del producto, esto es,
+la cantidad de tiempo que estará operativo.
+
+## Requerimientos operacionales y de entorno
+
+
+
+
+
+Detallar los requerimientos del entorno físico en el cual el sistema operará. En
+algunos productos, las diferentes condiciones especiales bajo las que operará el
+sistema generan requerimientos que se deben tener en cuenta.
+
+
+Definir los requerimientos que establecen las interacciones necesarias entre el
+sistema y otras aplicaciones o software. Tener en cuenta el versionado del
+software con el cual el sistema va a interactuar, por ejemplo: "El sistema
+deberá poder utilizar datos de la aplicación X en su versión 4.0".
+
+
+Definir todos los requerimientos de sistema necesarios para soportar la
+aplicación. Esto puede incluir plataformas de sistemas operativos, de redes,
+configuraciones, memoria, periféricos y software adicional necesario.
+
+
+
+
+
+En caso de que distribuir el producto esté dentro del alcance del proyecto,
+indicar los requerimientos necesarios para que el sistema sea distribuido o
+vendido como producto. Indicar también las tareas necesarias para que sea
+instalado, en caso de ser pertinente. Por ejemplo: "La aplicación debe ser
+distribuida en la App Store y Google Play Store en Uruguay" o, "La aplicación
+debe ser descargable desde el sitio web de la organización".
+
+
+En caso de establecer con el cliente un ciclo de releases durante un determinado
+período, indicarlo aquí como un requerimiento.
+
+## Requerimientos de mantenimiento y soporte
+
+
+
+
+
+Especificar aquellos requerimientos relacionados al mantenimiento del sistema
+por parte de los usuarios finales, administradores e incluso otros futuros
+desarrolladores. Por ejemplo: "El código debe ser escrito en inglés para que sea
+legible internacionalmente" o, "Un administrador de la aplicación debe ser capaz
+de agregar un recurso X en menos de 15 minutos para que sea visible por los
+usuarios" o, "Se debe entregar junto al producto un documento con notas de
+arquitectura del sistema que explique cómo está estructurado".
+
+
+Especificar los entornos o plataformas que el sistema deberá soportar, por
+ejemplo: "El sistema deberá ser capaz de correr en Android y iOS".
+
+
+En una solución completa se debe incluir documentos con las instrucciones de
+instalación y configuración. Establecer aquí los requerimientos para esos
+documentos.
+
+
+
+
+
+En caso de que el sistema incluya soporte o ayuda en línea de alguna forma
+específica —un chatbot, por ejemplo—, detallarlo aquí mediante requerimientos.
+
+
+En caso de que sea necesario desarrollar un manual de usuario, describir su
+propósito y contenido, esto es: extensión, nivel de detalle, índices, glosarios,
+etcétera. Si hay restricciones de formatos o de impresión, indicarlo.
+
+## Requerimientos de seguridad
+
+
+
+
+
+Detallar quiénes tienen acceso a las diferentes partes del producto (tanto en
+términos de funcionalidades como en términos de datos) y bajo qué
+circunstancias.
+
+
+Especificar la integridad requerida por la base de datos, archivos del sistema y
+el sistema en sí mismo. Por ejemplo: "El sistema deberá prevenir el ingreso de
+datos incorrectos" o, "El sistema deberá protegerse a sí mismo del uso
+malintencionado".
+
+
+Describir aquellos requerimientos que definen qué debe hacer o con qué debe
+cumplir el sistema para asegurar la privacidad de los datos compartidos por los
+usuarios. Por ejemplo: "El sistema debe notificar a los usuarios sobre el uso de
+sus datos personales" o, "El sistema debe notificar sobre cambios en la política
+de privacidad de los datos".
+
+
+Mencionar qué es lo que tiene que hacer el sistema para protegerse de
+infecciones de software como virus, gusanos, *malware*, *spyware*, etcétera.
+
+
+
+
+
+En caso de que el sistema deba soportar controles de auditoría, especificar lo
+que el sistema debe de hacer (usualmente, mantener información persistida) para
+permitirlos. Por ejemplo: "El sistema debe mantener datos sobre X para que sean
+auditados periódicamente".
+
+## Requerimientos culturales
+
+
+
+
+
+Opcionalmente, pueden existir requerimientos de carácter sociológico que afecten
+la aceptabilidad del sistema. Estos son de particular interés al desarrollar un
+sistema para el mercado extranjero. Por ejemplo: "El sistema deberá ser capaz de
+distinguir entre el enumerado de calles utilizado en Italia e Inglaterra", o,
+"El sistema deberá contemplar los feriados de la Unión Europea".
+
+## Requerimientos legales
+
+
+
+
+
+Detallar los requerimientos asociados a normas y regulaciones que el proyecto y
+cada uno de ustedes como desarrolladores del sistema deberán cumplir.
+
+
+Detallar los estándares con los cuales el producto deberá cumplir, si los hay.
+Por ejemplo, legales (FDA, UCC), de comunicaciones, de compatibilidad con
+plataformas, calidad y seguridad (UL, ISO, CMM).
diff --git a/1_Entregable_proyecto/1_1__Requisitos.md b/1_Entregable_proyecto/1_1__Requisitos.md
index 49526a1..d708a53 100644
--- a/1_Entregable_proyecto/1_1__Requisitos.md
+++ b/1_Entregable_proyecto/1_1__Requisitos.md
@@ -1,712 +1,11 @@
-# 1 Contenido
+# 1 Entregable del proyecto
## 1.1 Requisitos
-El propósito de esta sección es reunir, analizar, definir y especificar las
-necesidades del usuario y las funcionalidades del sistema.
+### 1.1.1 [Impulsores del proyecto](./1_1_1_Impulsores_del_proyecto.md)
-### Glosario
+### 1.1.2 [Restricciones del proyecto](./1_1_2_Restricciones_del_proyecto.md)
-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.
+### 1.1.3 [Requerimientos funcionales](./1_1_3_Requerimientos_funcionales.md)
-### Posicionamiento del proyecto
-
-Esta subsección da un resumen general del proyecto.
-
-#### 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.
-
-#### Declaración del problema
-
-Sin entrar en detalles, describir el problema que este proyecto intenta
-resolver. Opcionalmente se puede utilizar el siguiente formato:
-
-| El problema | (descripción del problema) |
| Afecta a | (stakeholders afectados) |
| Cuyo impacto es | (¿cuál es el impacto del problema?) |
| Una solución exitosa debe tener | (listar algunos beneficios - clave de una solución exitosa) |
| Descripción | Descripción breve del usuario y la relación que - tendrá con el sistema. |
| Representado por | 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” |
| Rol en la organización | Descripción del rol que desempeña en - la organización cliente. |
| Rol en el sistema | Descripción del rol que tendrá con respecto - a la operación del sistema. Por ejemplo: “este usuario ingresará los datos de - ventas”. |
| Perfil técnico | 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. |
| Criterio de éxito | ¿Cómo el usuario define el éxito del - proyecto? ¿Qué factores determinan el éxito del proyecto según el usuario? |
| Comentarios | Comentarios sobre el usuario. |
| Descripción | Breve descripción de la necesidad y sus motivos. |
| Prioridad | ¿Qué nivel de prioridad tiene esta necesidad? |
| Concierne a | ¿A quién concierne esta necesidad? |
| Solución actual | ¿Cuál es la solución actual para esta necesidad? |
| Solución propuesta | ¿Qué solución propone el sistema ante esta - necesidad? |
:
+> Todo lo indicado a continuación hasta la próxima etiqueta es de carácter
+> obligatorio a efectos del entregable del proyecto.
+>
+>