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ónDescripción breve del usuario y la relación que + tendrá con el sistema.
Representado porStakeholders 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ónDescripción del rol que desempeña en + la organización cliente.
Rol en el sistemaDescripción del rol que tendrá con respecto + a la operación del sistema. Por ejemplo: “este usuario ingresará los datos de + ventas”.
Perfil técnicoDescribir 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?
ComentariosComentarios 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ónBreve 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.