diff --git a/.markdownlint.json b/.markdownlint.json
index 41ad1ef..a528d68 100644
--- a/.markdownlint.json
+++ b/.markdownlint.json
@@ -1,4 +1,7 @@
{
+ "MD013": {
+ "tables": false
+ },
"MD033": false,
"MD041": false
}
diff --git a/1_Contenido/1_1__Requisitos.md b/1_Contenido/1_1__Requisitos.md
index e39c790..55d08c9 100644
--- a/1_Contenido/1_1__Requisitos.md
+++ b/1_Contenido/1_1__Requisitos.md
@@ -1,3 +1,416 @@
# 1 Contenido
## 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.
+
+### Glosario
+
+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.
+
+### 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) |
+
+
+#### 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. **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?_
+
+#### Objetivos del proyecto
+
+
+
+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_ |
+| ... | ... | ... | ... |
+
+### Interesados (_stakeholders_)
+
+
+
+Esta subsección busca analizar a los interesados en el proyecto. Para ello, se
+presenta: el cliente del proyecto, el comprador o consumidor del producto,
+usuarios del producto y otros interesados.
+
+#### Cliente del proyecto
+
+
+
+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.
+
+#### Comprador o consumidor del producto
+
+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.
+
+#### Usuarios
+
+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. |
+
+
+##### 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?_
+
+##### Entornos de los usuarios
+
+Detallar el ambiente de trabajo del usuario objetivo. **Algunas preguntas
+disparadoras**:
+
+- Número de personas involucradas en la tarea. ¿Es cambiante?
+
+- ¿Cuán extenso es el ciclo de una tarea? ¿Cuánto tiempo se dedica a cada
+ actividad? ¿Es cambiante?
+
+- Restricciones ambientales particulares: móviles, exteriores, en vuelo, etc.
+
+- ¿Qué plataformas de sistemas se encuentran en uso actualmente? ¿Y plataformas
+ futuras?
+
+- ¿Qué otras aplicaciones están en uso? ¿Precisa esta aplicación ser integrada
+ con ellas?
+
+#### 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, mencionar: 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.
+
+### 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:
+
+
+ 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? |
+
+
+### Contexto del trabajo
+
+Esta subsección busca determinar los límites del trabajo a realizar y cómo
+encaja en su entorno.
+
+#### Situación actual
+
+
+
+Mediante un modelo de procesos de negocio, denotar los procesos de negocio
+pertinentes que existen actualmente y que pueden ser reemplazados o cambiados
+por la solución a desarrollar.
+
+#### Interfaces pertinentes al trabajo
+
+A alto nivel y mediante un diagrama, explicar las interacciones de la solución
+con entidades adyacentes a la misma (otras personas, organizaciones, hardware y
+software) y el input/output de estas interacciones.
+
+#### Eventos y casos de uso del negocio
+
+
+
+A alto nivel, listar todos los eventos de negocio a los que el trabajo a
+desarrollar responde (es decir, casos de uso del negocio), indicando: nombre del
+evento de 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 de negocio | Input y output | Descripción del caso de uso del negocio |
+| -------------------------------- | ---------------------------------------------- | ------------------------------------------------- |
+| _(Nombre del evento de negocio)_ | _(Input y output del caso de uso del negocio)_ | _(Breve descripción del caso de uso del negocio)_ |
+
+#### Especificación de los casos 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.
+
+#### Resumen de capacidades
+
+Resumir los beneficios y características más importantes que el sistema ha de
+proveer. Por ejemplo, si el sistema en cuestión fuera un sistema de atención al
+cliente, en esta parte se abordaría la gestión de documentación de problemas
+comunes, gestión de reclamos, telefonistas, etc., sin mencionar la cantidad de
+detalle que cada una de estas partes requiere. Organizar las funciones de forma
+que la lista resulte comprensible para el cliente o para cualquier otro que lea
+el documento por primera vez. Una tabla sencilla que resuma los beneficios clave
+y las características que los hacen posibles puede ser suficiente. Por ejemplo:
+
+| Beneficio para el cliente | Característica que produce el beneficio |
+| ------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Un nuevo equipo de soporte puede rápidamente ponerse a tono. | Una base de conocimientos asiste al personal de soporte identificando rápidamente las fallas conocidas y sus soluciones. |
+| La Administración puede identificar las áreas problema y medir la carga de trabajo del equipo. | Los reportes de tendencias permiten una vista de alto nivel del estado del problema. |
+| Los equipos de soporte distribuidos pueden trabajar juntos para resolver problemas. | El servidor de replicación permite que la información de la base de datos actual sea compartida a través de la empresa. |
+| Los clientes se pueden ayudar a sí mismos, bajando los costos de soporte y mejorando el tiempo de respuesta. | La base de conocimientos puede ser habilitada a través de Internet. Incluye capacidades de búsqueda con hipertexto y una máquina de consulta gráfica. |
+
+#### Asunciones y dependencias
+
+Listar los asunciones que, si fueran cambiadas, cambiarían las capacidades del
+producto tal 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.
+
+#### Costos y precios
+
+Las características de costo y precio pueden impactar directamente a la
+definición e implementación de la aplicación. En esta parte se deben registrar
+todas las restricciones de costos y precios que sean relevantes. Por ejemplo,
+adquisición de hardware para el sistema.
+
+#### Instalación
+
+Listar las características de instalación, ya que estas pueden también impactar
+directamente al esfuerzo de desarrollo. Por ejemplo, brindar serialización o
+seguridad con encriptación requerirá esfuerzos adicionales de desarrollo. Los
+requerimientos de instalación también pueden afectar a la codificación, o crear
+la necesidad de un software de instalación separado.
+
+#### Alternativas competitivas
+
+Identificar las alternativas que la organización cliente percibe como
+disponibles. Éstas 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. Listar todas las alternativas
+competitivas existentes, o que puedan volverse disponibles, incluyendo los
+productos existentes de la competencia. Incluir las debilidades y fortalezas más
+importantes de cada una, en el contexto de la organización cliente.
+
+### Restricciones
+
+Esta subsección detalla las diferentes restricciones de diseño o restricciones
+externas que se impongan para el desarrollo del producto.
+
+#### Restricciones de diseño y tecnologías
+
+Cada una de las restricciones mencionadas en esta parte debe usar el [template
+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 debe ser una aplicación web? ¿debe ser una aplicación mobile? ¿debe
+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.
+
+#### 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 debe 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.
+
+#### Restricciones de utilización de software externo
+
+Utilizando el [template de requerimiento
+atómico](../3_Plantillas/3_1_Requerimiento_atomico.md), mencionar las
+restricciones existentes sobre la utilización de software externo. Esto es: la
+obligación de que la solución se integre con con un software externo específico.
+
+#### Restricciones organizacionales
+
+Utilizando el [template de requerimiento
+atómico](../3_Plantillas/3_1_Requerimiento_atomico.md), detallar aquellas
+restricciones provenientes de las políticas de la organización/empresa cliente.
+
+#### 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 restricción 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.
+
+#### Restricciones de presupuesto
+
+Mencionar el presupuesto del proyecto expresado en términos monetarios o
+recursos disponibles.
+
+Los requerimientos no deben exceder el presupuesto, así que esta restricción
+determina qué requerimientos son incluidos en el producto.
+
+### Precedencia y prioridad
+
+Definir las prioridades de las diferentes funcionalidades del producto.
+
+### Otros requerimientos del producto
+
+Utilizando el [template de requerimiento
+atómico](../3_Plantillas/3_1_Requerimiento_atomico.md), listar todos los
+estándares aplicables, requerimientos de plataformas o hardware, requerimientos
+de rendimiento y requerimientos ambientales.
+
+#### Estándares aplicables
+
+Listar los estándares con los cuales el producto debe cumplir, si los hay. Por
+ejemplo, legales (FDA, UCC), de comunicaciones, de compatibilidad con
+plataformas, calidad y seguridad (UL, ISO, CMM).
+
+#### Requerimientos del sistema
+
+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.
+
+#### Requerimientos de rendimiento
+
+Indicar los requerimientos de rendimiento, si los hay. Puede incluir
+características tales como factores de carga de usuarios, anchos de banda o
+capacidad de comunicaciones, precisión, confiabilidad o tiempos de respuesta
+bajo condiciones de carga variadas.
+
+#### Requerimientos ambientales
+
+Detallar los requerimientos ambientales necesarios, si los hay. Para sistemas de
+hardware, estos requerimientos pueden incluir temperatura, humedad, radiación,
+etc. Para aplicaciones de software, los factores ambientales pueden incluir
+condiciones de uso, ambiente del usuario, disponibilidad de recursos,
+mantenimiento, recuperación.
+
+#### Rangos de calidad
+
+Definir los rangos de calidad requeridos para características no funcionales,
+por ejemplo: rendimiento, robustez, tolerancia a fallos, usabilidad, y
+características similares que no se hayan capturado en el conjunto de
+funcionalidades.
+
+### Requerimientos de documentación
+
+Esta subsección describe la documentación que debe ser desarrollada para
+soportar una implantación exitosa del sistema.
+
+#### Manual de usuario
+
+Describir el propósito y contenido del manual de usuario: extensión, nivel de
+detalle, índices, glosarios, etcétera. Si hay restricciones de formatos o de
+impresión, indicarlo.
+
+En caso de que no haya manual de usuario, indicarlo.
+
+#### Ayuda en línea
+
+Muchas aplicaciones proveen un sistema de ayuda en línea para asistir al
+usuario. La naturaleza de estos sistemas es específica del desarrollo de la
+aplicación debido a que combinan aspectos de programación con aspectos de texto
+técnico (organización, presentación). En muchos casos, se ha encontrado que el
+desarrollo del sistema de ayuda es un proyecto dentro del proyecto, que
+beneficia a la administración del alcance y a las actividades de planificación.
+Utilizando el [template de requerimiento
+atómico](../3_Plantillas/3_1_Requerimiento_atomico.md), especificar aquí los
+requerimientos de ayuda en línea, si los hay.
+
+En caso de que no haya ayuda en línea, indicarlo.
+
+#### Guías de instalación y configuración
+
+En una solución completa se debe incluir documentos con las instrucciones de
+instalación y configuración. Utilizando el [template de requerimiento
+atómico](../3_Plantillas/3_1_Requerimiento_atomico.md), establecer aquí los
+requerimientos para esos documentos.