CosmoSys-Req » History » Revision 2
Revision 1 (Redmine Admin, 09/20/2026 10:35 PM) → Revision 2/19 (Redmine Admin, 09/21/2026 01:05 AM)
# cosmoSys-Req **cosmoSys-Req es un [[Gestor [[gestor de requisitos]] libre, abierto y gratuito para ingeniería de sistemas.** Se construye sobre [[cosmoSys]] y Redmine para que los requisitos no vivan en una base de datos aislada: comparten proyectos, usuarios, documentos y mecanismos de colaboración con el resto del trabajo de ingeniería, pero conservan su identidad, sus atributos y su ciclo de revisión propios. Si ya trabajas con conoces la ingeniería de requisitos, aquí puedes ver qué aporta la herramienta. empezar directamente a trabajar con él. Si no, [[Gestor de requisitos]] explica primero no conoces bien qué información se gestiona y por qué una hoja de cálculo empieza a quedarse corta cuando el sistema crece.  ## Requisitos++ Cada requisito recibe es un **CSID estable y legible**, como `M2-0027`, que puede conservar aunque el ítem cambie gestor de capítulo requisitos o cómo se mueva dentro del árbol trabaja con requisitos, [puedes consultar esta explicación](#). cosmoSys-Req proporciona las capacidades habituales de proyectos. Junto al texto se pueden mantener su tipo y nivel, la justificación, la fuente gestión de derivación, los métodos requisitos —identificación, clasificación, relaciones, trazabilidad, verificación y la descripción de verificación, documentación— y las integra en un entorno colaborativo donde la información de cumplimiento e implementación que corresponda. del proyecto puede seguir conectada mientras evoluciona. La herramienta separa dimensiones que Pero cosmoSys no se limita a menudo se mezclan: - la **jerarquía del libro** indica dónde se presenta el requisito; - las **relaciones** indican de qué depende, qué bloquea o con qué está conectado; - la **derivación** conserva el requisito del gestionar requisitos. Su propósito es que procede; - el **workflow** expresa su madurez los requisitos formen parte de redacción y revisión; - la **verificación y el cumplimiento** describen cómo se evaluará y qué resultado se ha obtenido. Por eso un requisito puede reorganizarse en la especificación sin perder su procedencia, y dos requisitos cercanos en el documento no tienen por qué fingir una dependencia que no existe. ## Ayudas al proceso **modelo de creación de requisitos La acción **Derive** ayuda a crear requisitos derivados como una operación coherente: sitúa los nuevos ítems, registra la fuente información del proyecto**, junto con sus documentos, relaciones, decisiones y crea las relaciones causales. El usuario sólo tiene que nombrar y describir los nuevos requisitos, ahorrándose el tedio demás elementos de establecer las relaciones una a una. ingeniería. --- ## Gestión de características, datos Del requisito al modelo del proyecto cosmoSys incorpora `csDatum`, un diccionario de datos común al árbol de proyectos. Una definición reúne una clave estable, especificación puede ser un nombre legible documento excelente y seguir siendo una fotografía del conocimiento del equipo en un valor textual con sus unidades o interpretación. momento determinado. Así, un requisito puede almacenar: ```text The mirror system shall reach ${AverageThroughput.value} average throughput. ``` Los gestores de requisitos permiten estructurar esa información: los requisitos tienen identidad, jerarquía, relaciones, procedencia, metadatos, estados y presentar el valor vigente —por ejemplo, *85%*— sin duplicarlo en cada texto. `${AverageThroughput}` presenta el nombre legible y `${AverageThroughput.value}` el valor. Las expresiones desconocidas permanecen visibles para que la falta métodos de información no quede escondida. Los datos utilizados se registran durante la generación del informe verificación. También permiten recorrer sus relaciones y pueden formar una tabla de metadatos. Además, mantener la evidencia trazabilidad necesaria para comprender de aprobación permite advertir si cambiar un dato ha alterado realmente el significado de un dónde procede cada requisito consolidado. `csDatum` sigue siendo texto: el cálculo de fórmulas, las magnitudes tipadas y los motores automáticos de evaluación pertenecen a una evolución posterior.  él. ## Ciclo de vida **cosmoSys-Req lleva esa información un paso más allá al integrarla en el modelo general del requisito proyecto.** El ciclo básico distingue `Draft`, `Stable` Los requisitos pueden relacionarse con tareas, documentos, decisiones y `Approved`: redacción, texto preparado para revisión y requisito aceptado. `Rejected` y `Erased` son cierres negativos; no equivalen a destruir físicamente el ítem. Su identidad, contenido, historial, posición y relaciones permanecen disponibles para trazabilidad y recuperación autorizada, aunque las vistas otros elementos de ingeniería, manteniendo esas conexiones dentro del contenido vigente puedan ocultarlos por defecto. mismo entorno. Los estados cerrados también tienen significado. Un requisito aprobado es contenido consolidado, La diferencia no una tarea «terminada» que deba desaparecer o mostrarse tachada. cosmoSys-Req conserva los requisitos aprobados está sólo en dónde se escribe el árbol y requisito. Está en la especificación, **qué información puede mantenerse conectada a su alrededor y distingue los cierres satisfactorios de las retiradas o rechazos. cómo puede utilizarse después**. --- ## Control de consistencia Cada requisito tiene una historia Una relación de bloqueo puede representar una dependencia causal: si un Un requisito rara vez aparece de sistema da origen a otro más concreto, el requisito fuente bloquea al derivado. El derivado no debería aparecer más maduro que aquello de lo que deriva. la nada. cosmoSys-Req asigna niveles Puede proceder de madurez a los estados y comprueba la cadena bloqueante. Si un requisito `Approved` depende de otro que vuelve a `Draft`, la inconsistencia se hace visible. Los diagramas la resaltan en rojo y la presentación una necesidad del requisito explica el problema; el sistema no cambia estados silenciosamente ni pretende sustituir la usuario, una norma, una decisión del revisor. ### Control del texto realmente aprobado Comprobar sólo inconsistencias a partir de los estados diseño, una restricción de los requisitos otro subsistema o de cambios en sus propios textos (descripción, justificación...) no basta. una conclusión obtenida durante el desarrollo. Un requisito seguirá en `Approved` aunque se haya cambiado un dato del proyecto que utiliza. Si un requisito depende gestor de otro que se modifica y se aprueba de nuevo, también podría dejar de detectarse la inconsistencia. Esto es muy común en sistemas de gestión de requisitos que basan su detección de consistencias en localizar requisitos que dependen de otros menos maduros. debe permitir conservar esas relaciones. cosmoSys-Req dispone de mecanismos para impedir que estos cambios pasen inadvertidos. Cada vez que aumenta la madurez, cosmoSys-Req guarda evidencia **cosmoSys-Req permite además navegar por ellas como parte del texto **explícito** que se revisó y modelo del contexto transitivo de requisitos que lo bloqueaban. Es decir, obtiene una fotografía del texto que el revisor analizó y consideró válido e incluye también los textos de todos los requisitos de los que dependía, recorriendo toda la cadena de dependencias. La fotografía de esa transición se registra y actúa como referencia hasta el siguiente aumento de madurez. proyecto.** Cada vez que un requisito va Puedes derivar requisitos, relacionarlos con otros requisitos, asociarlos a mostrarse, se toma una instantánea efímera que se compara con la de referencia: documentos y mantener información sobre cómo deben verificarse. Así, cuando alguien pregunta: - si cambia porque cambió un `csDatum`, detecta la diferencia; - si cambia el texto de un requisito antecedente, la detecta; - si se añade, elimina o reorganiza una dependencia de la cadena, también la detecta. > ¿Por qué tenemos este requisito? Cuando existe deriva, la vista muestra el aviso y, para el texto respuesta puede estar dentro del propio requisito, un diff entre proyecto. Y cuando alguien pregunta: > ¿Qué se ve afectado si lo aprobado y lo actual. La forma usual de aceptar el cambio es bajar la madurez, revisar y volver a subirla (por ejemplo Approved -> Draft -> Stable -> Approved). La configuración de workflows, roles y permisos permite reservar esas transiciones al equipo revisor que corresponda. cambiamos? Si se revierten los cambios que causaron la inconsistencia, cosmoSys-Req retira las advertencias, pues el requisito vuelve relaciones del modelo pueden ayudar a expresarse exactamente igual que en encontrar la fotografía respuesta. --- ## Ver el proyecto antes de referencia. De esa manera, un cambio accidental no dispara toda una cadena de trabajo. leerlo entero Estas revisiones de la consistencia Los proyectos complejos son una ayuda a la revisión: no una promesa difíciles de consistencia transaccional ni un sustituto de la responsabilidad técnica sobre el documento entregado. Es un mecanismo de calidad contra errores, no una garantía ante negligencias ni sabotajes. ## Trazabilidad que comprender cuando sólo se puede ver y navegar presentan como listas. La jerarquía, las relaciones y las referencias no quedan escondidas en columnas dispersas. cosmoSys **cosmoSys genera diagramas directamente a partir del modelo vigente: - diagramas jerárquicos, para comprender el libro y sus capítulos; - diagramas de dependencias, para recorrer causas y consecuencias; - diagramas combinados, que expresan a la vez información real del proyecto.** Las jerarquías, dependencias y jerarquías; relaciones pueden verse gráficamente y utilizarse para explorar el modelo. Los diagramas no No son simples dibujos que haya alguien tenga que actualizar a mano. Se regeneran desde los mismos ítems y relaciones que consulta mantener aparte. **El diagrama nace del modelo.** Por eso puede utilizarse para comprender el equipo proyecto mientras se trabaja y pueden también incorporarse después a la documentación. También son navegables para agilizar su análisis. Se acabó perder el hilo buscando en una matriz o buscando códigos en el proyecto para averiguar de qué otros requisitos dependía el requisito del documentación que deriva el actual. se entrega.  --- ## Referencias documentales enriquecidas Trabajar juntos sobre la misma información La colaboración sobre requisitos no es una idea exclusiva de cosmoSys. Las normas, especificaciones herramientas de nivel superior, manuales o evidencias pueden catalogarse como documentos gestión de referencia, aplicables o de cumplimiento, creando referencias como RD.1, AD.1 o CD.1, muy útiles cuando se genere el informe, al estilo de un documento o artículo de ingeniería. Normalmente son los documentos los requisitos permiten que referencian a otros documentos, pero distintas personas participen en cosmoSys-Req cada ítem puede referenciar documentos. Cada requisito puede mantener la definición, revisión y seguimiento de una lista de referencias sin limitación de número o familia documental. especificación. Además, cada referencia desde un ítem puede, a discreción del usuario, tener su propio **sentido** —por qué se usa— y su **localización** —capítulo, página, tabla o anexo relevante—, **cosmoSys-Req lo que ayuda al equipo a entender por qué ese ítem referencia ese documento y a encontrar hace dentro de él una aplicación web colaborativa**, donde las personas que participan en el texto de interés. Las etiquetas del catálogo se calculan automáticamente. Una cita textual conserva una identidad interna estable proyecto pueden trabajar sobre la misma información, con roles, permisos y sigue apuntando workflows adaptados al documento correcto aunque el catálogo cambie proceso de orden, evitando mantener a mano referencias como `RD.2` o `AD.4` repartidas por toda la especificación. Si un usuario intercambia las entradas que en ese momento se muestran como `RD.5` organización. La revisión deja de depender exclusivamente de intercambiar documentos. El equipo puede trabajar sobre la especificación, discutirla, derivarla, revisarla y `RD.6`, las citas presentan seguir sus nuevas etiquetas sin modificar su destino ni el Markdown almacenado. El diseño separa así un simple cambio de numeración relaciones dentro del contenido esencial mismo entorno. --- ## La documentación se genera desde lo que fue revisado, para evitar inconsistencias fantasma. realmente existe > **Comportamiento protegido — prueba Los gestores de regresión pendiente:** esta separación forma parte del contrato requisitos pueden generar documentos y exportaciones de cosmoSys y no debe deshacerse. Está pendiente confirmar automáticamente la información que el intercambio actualiza las etiquetas visibles tanto contienen. **cosmoSys-Req pone especial énfasis en la vista como en el informe sin invalidar la línea base aprobada; esta etiqueta se retirará cuando exista calidad de esa cobertura. documentación.** ## Generación de informes de calidad El La información del proyecto puede leerse como un libro: capítulos, requisitos, transformarse en documentos estructurados que incluyen jerarquías, metadatos, referencias y diagramas forman una vista HTML que se revisa antes de exportar. Las diagramas, utilizando plantillas adaptables a las necesidades de LibreOffice controlan la presentación final y permiten producir documentos editables o PDF sin convertir una tabla cada organización. Los diagramas generados por cosmoSys pueden formar parte de cientos esos documentos, de columnas en manera que la especificación oficial. La documentación procede de la misma información sobre la represente realmente el modelo que trabaja el equipo. No elimina la necesidad equipo está utilizando. El documento deja de establecer baselines o revisar ser una entrega concreta, pero evita segunda fuente de información que alguien tiene que mantener por separado manualmente. **Es una representación del proyecto que puede generarse cuando se necesita.** --- ## Las referencias también tienen contexto En ingeniería no basta con saber que un modelo vivo y un documento existe. Hay que empieza a envejecer desde el momento en que saber **por qué se copia. cita**, qué parte resulta aplicable y dónde se encuentra la información relevante.  Los proyectos gestores de requisitos pueden tener versiones, mantener referencias hacia documentación externa. **cosmoSys añade contexto a esas referencias**, permitiendo relacionar documentos con elementos concretos del proyecto y los requisitos pueden asociarse a aquella en la que se han conservar información sobre el documento, su versión, su localización y el sentido de consolidar. En la pestaña Roadmap se relación. Así, un mismo documento puede consultar utilizarse en qué versión distintos lugares sin perder el motivo concreto por el que se espera consolidar cita en cada requisito uno. --- ## Variables, modelos y cuántos quedan pendientes para poder cerrar una entrega. otra información de ingeniería El informe muestra la versión que el Un proyecto tenga configurada como predeterminada. de ingeniería no está compuesto únicamente por requisitos. Los informes no parecen como volcados de una hoja de cálculo, con demasiadas columnas Hay valores, parámetros, restricciones, decisiones, componentes, documentos y textos largos apretados en una otros tipos de ellas mientras en otras se derrocha espacio. Los informes parecen libros de especificaciones legibles y bien formateados. El usuario determina si cada metadato se presenta en una tablilla tras la descripción del requisito o como un apartado más del requisito dentro del cuerpo del texto. cosmoSys-Req ofrece también capítulos especiales información que se autogeneran. Por ejemplo, pueden ser relevantes para comprender el usuario puede situar en el árbol un marcador para generar un capítulo de referencias documentales, otro de sistema. **cosmoSys permite incorporar esta información al modelo del proyecto mediante variables y elementos eliminados y otro con los configurables**, evitando que determinados datos del proyecto. El usuario decide libremente tengan que quedar aislados en qué lugar del documento se muestran. El informe contendrá esas secciones con sus tablas correspondientes, autogeneradas por documentos o herramientas independientes. Esto permite utilizar la herramienta, y presentadas como cabría misma infraestructura de esperar en información para representar diferentes aspectos de un documento técnico. proyecto, según las necesidades de cada organización. Los diagramas también pueden incorporarse a los informes acompañando a cada requisito. Para cada uno se puede escoger de forma independiente qué diagrama mostrar: ninguno, dependencias, jerarquía o combinado. --- ## Y el proyecto sigue siendo tuyo cosmoSys-Req incluye además está construido sobre **software libre** y utiliza mecanismos y formatos abiertos para preservar su legibilidad y evitar tediosos postprocesos facilitar el intercambio de ajuste estético manual. Por ejemplo, si el documento utiliza una plantilla con orientación vertical y cosmoSys-Req estima información. No hay licencias por usuario que un diagrama tendría que reducirse demasiado para caber limiten quién puede participar en el ancho disponible, puede moverlo a proyecto. No hay una página con orientación apaisada, siempre suscripción que determine si puedes seguir utilizando la plantilla proporcione esa página alternativa y el cambio mejore herramienta. **Puedes instalar cosmoSys, estudiar su escala. ## Exportaciones funcionamiento, adaptarlo e integrarlo con revisión previa otros sistemas.** Los requisitos pueden La API facilita la interoperabilidad y la información del proyecto puede exportarse a una hoja de cálculo ODS (compatible con Excel) útil para revisión o trabajo temporal fuera ser procesada mediante otras herramientas. Tus requisitos son conocimiento de línea. También pueden importarse por el mismo método. tu organización. Al volver **La herramienta debe ayudarte a cargarla, cosmoSys gestionarlos, no aplica los cambios a ciegas: prepara una transferencia, compara altas y modificaciones, detecta incidencias y exige confirmación. convertirse en su propietario.** La plantilla específica --- ## No necesitas cambiar toda tu forma de requisitos conserva sus campos propios y las hojas DSM, que pueden resultar muy útiles para revisar dependencias sin conexión. trabajar cosmoSys-Req también comprueba el linaje de la hoja al cargar. Así puede detectar cambios concurrentes respecto no pretende obligar a la exportación de origen y evitar que dos ramas del mismo ODS sobrescriban silenciosamente el proyecto. todos los equipos a trabajar exactamente igual. ## Extensiones al requisito **cosmoSys permite configurar proyectos mediante perfiles, campos, roles, permisos y su ciclo workflows**, de vida Algunas organizaciones utilizan manera que la gestión de requisitos como otra vista más del avance del proyecto. Un requisito aprobado puede además marcarse como incluido cuando su implementación se incorpora al sistema en desarrollo, y como validado cuando supera sus validaciones. De esa manera se evita crear tareas asociadas sólo misma base pueda utilizarse para este seguimiento y se procesos con necesidades diferentes. También puede saber si una entrega está lista consultando los requisitos aún convivir con otras herramientas. La interoperabilidad no validados. El equipo de QA puede identificar qué requisitos podrían validarse observando cuáles están incluidos. No es un uso canónico añadido posterior: forma parte de los gestores la idea de requisitos, pero sí mantener el conocimiento bajo el control del equipo. --- ## Un ejemplo sencillo Imagina que un uso extendido. equipo está desarrollando un instrumento. En nuestra experiencia con versiones anteriores Al principio existe una necesidad: **el instrumento debe poder operar dentro de cosmoSys-Req, donde los requisitos seguían mostrando campos típicos de las tareas —como fechas o personas asignadas—, algunas organizaciones utilizaban esos campos para determinar quién debía redactar cada requisito o cuándo debía estar consolidado. determinadas condiciones.** De esa manera combinaban la potencia del gestor de necesidad se derivan requisitos con la de un gestor sistema. Algunos pasan a ser responsabilidad de tareas. Como en el caso anterior, no es un uso canónico, pero sí extendido. Por tanto, cosmoSys-Req incluye por defecto cuatro tipos óptica, otros de ítem para representar requisitos: - `csRq`: redacción mecánica, electrónica o software. Aparecen documentos aplicables y gestión del requisito, uso canónico; - `csRqm`: añade asignación, fechas, esfuerzo y progreso decisiones de trabajo, combinando diseño. Cada requisito y tarea; - `csRqr`: añade seguimiento ligero necesita finalmente una forma de inclusión y validación en una entrega; - `csRqmr`: combina `csRqm` y `csRqr`. comprobar que se cumple. ## Colaborar sin entregar el modelo a un proveedor cosmoSys-Req Esta es una aplicación web multiusuario sobre Redmine. Roles, permisos, workflows, proyectos y subproyectos permiten repartir visibilidad y responsabilidad sin precisamente la clase de información que cada participante mantenga debe poder gestionar una copia privada herramienta de la especificación. requisitos. Es también **software libre, abierto y gratuito**. **cosmoSys-Req permite además mantener estas relaciones dentro del modelo del proyecto:** **necesidad → requisito → derivación → diseño → documento → verificación** No hay licencias por puesto se trata de que obliguen a dejar fuera de cosmoSys haga la revisión a parte del ingeniería por el equipo. La organización conserva la instalación y los datos, puede auditar el código y dispone Se trata de formatos abiertos, exportaciones, snapshots y la API de Redmine para evitar que **el equipo pueda hacer ingeniería sin perder las conexiones que explican lo que está haciendo**. --- ## Cuando el conocimiento quede secuestrado. proyecto cambia La generación actual es una refundación técnica Los proyectos cambian. Cambian los requisitos, aparecen nuevas restricciones, se descubren errores, se sustituyen componentes y conceptual de un sistema utilizado desde 2019. Continúa en evolución activa: conviene evaluarla de forma controlada y comprobar cada entrega, como corresponde se toman decisiones que afectan a cualquier herramienta que participa en un proceso de ingeniería. otras partes del sistema. ## Snapshots, copias y plantillas En cualquier instante, un usuario puede guardar un snapshot inmutable del estado material El valor de uno o varios proyectos seleccionados. El paquete `.csys` descargable es mantener un ZIP abierto y sencillo: contiene un manifiesto JSON y los ficheros binarios organizados por contenido para evitar duplicados. Al materializar modelo conectado aparece precisamente entonces. **En cosmoSys-Req, las relaciones que se han construido durante el snapshot o copiar directamente un trabajo permanecen disponibles cuando el proyecto se puede escoger entre evoluciona.** Un cambio no es sólo editar una copia fiel, que conserva el estado material y frase: puede preservar los CSID utilizarse la información relacionada para descubrir qué más debe revisarse. Y cuando no haya colisiones, y una copia limpia, que reinicia el estado de trabajo y genera normalmente nuevas identidades. Esto permite guardar un proyecto patrón y levantar nuevos proyectos a partir de él. Como continúa en cosmoSys los proyectos pueden subdividirse en forma manos de árbol, las copias pueden hacerse de proyectos individuales otro equipo o como una selección de todos o algunos proyectos otra persona, las relaciones siguen formando parte del mismo árbol. conocimiento del proyecto. El usuario también puede optar por copiar directamente un proyecto en otro, --- ## Abierto, gratuito y preparado para crecer cosmoSys nació con opciones similares, sin necesidad una idea sencilla: las capacidades de descargar previamente el paquete. ingeniería que una organización necesita para desarrollar sistemas complejos no deberían quedar reservadas a quienes pueden pagar determinadas licencias. Ambos procesos se benefician de un sistema de carga Por eso **cosmoSys es software libre, abierto y gratuito**. Puedes utilizarlo, estudiarlo, adaptarlo e integrarlo con `preflight`, en otras herramientas. Puedes mantener el que un asistente irá informando control de los cambios a acometer y permitiendo tus datos y, si algún día decides utilizar otra solución, puedes llevártelos contigo. **No tienes que el usuario tome las decisiones oportunas confiar en nosotros para controlar esa carga. conservar tu propio conocimiento.** ## Lo --- # Empieza por el problema que quieres resolver cosmoSys-Req tiene muchas funciones, pero no decide por ti necesitas conocerlas todas para empezar. La herramienta estructura información, conserva evidencias Si tu equipo necesita: * gestionar requisitos de forma estructurada; * mantener la trazabilidad entre necesidades, requisitos y hace visibles muchas incoherencias. No determina si un requisito está bien escrito, no demuestra por sí sola que otros elementos; * visualizar las relaciones del proyecto mediante diagramas generados desde el sistema lo cumpla y no convierte modelo; * trabajar sobre una mala relación en una buena decisión especificación compartida; * generar documentación de ingeniería. Su propósito es más útil y más realista: que ingeniería a partir de la información real del proyecto; * conservar el equipo pueda encontrar el origen contexto de las referencias documentales; * incorporar variables y otra información al modelo; * trabajar con una decisión, comprender sus consecuencias, revisar qué ha cambiado herramienta libre, abierta y producir una representación coherente gratuita; * o simplemente disponer de lo que sabe en ese momento. El resultado no es simplemente una lista alternativa abierta a las herramientas comerciales de gestión de requisitos, sino **cosmoSys-Req puede ser un **libro vivo y un modelo conectado del proyecto**.  partida.** ## Para seguir - [[Gestor de requisitos]] — qué información gestiona esta clase de herramientas. - [[cosmoSys]] — árboles, diagramas, informes, documentos, ODS y reutilización de proyectos. - [[Guía funcional de cosmoSys]] — explicación detallada de las capacidades compartidas y su uso. [Ver una demostración](#) · [Instalar cosmoSys-Req](#) · [Leer la documentación](#)
