Project

General

Profile

Wiki » History » Version 1

Redmine Admin, 09/20/2026 10:32 PM

1 1 Redmine Admin
# cosmoSys-Req
2
3
**cosmoSys-Req es un [[gestor de requisitos]] libre, abierto y gratuito para ingeniería de sistemas.**
4
5
Si ya conoces la ingeniería de requisitos, puedes empezar directamente a trabajar con él. Si no conoces bien qué es un gestor de requisitos o cómo se trabaja con requisitos, [puedes consultar esta explicación](#).
6
7
cosmoSys-Req proporciona las capacidades habituales de la gestión de requisitos —identificación, clasificación, relaciones, trazabilidad, verificación y documentación— y las integra en un entorno colaborativo donde la información del proyecto puede seguir conectada mientras evoluciona.
8
9
Pero cosmoSys no se limita a gestionar requisitos. Su propósito es que los requisitos formen parte de un **modelo de información del proyecto**, junto con sus documentos, relaciones, decisiones y demás elementos de ingeniería.
10
11
---
12
13
## Del requisito al modelo del proyecto
14
15
Una especificación puede ser un documento excelente y seguir siendo una fotografía del conocimiento del equipo en un momento determinado.
16
17
Los gestores de requisitos permiten estructurar esa información: los requisitos tienen identidad, jerarquía, relaciones, procedencia, metadatos, estados y métodos de verificación. También permiten recorrer sus relaciones y mantener la trazabilidad necesaria para comprender de dónde procede cada requisito y qué elementos dependen de él.
18
19
**cosmoSys-Req lleva esa información un paso más allá al integrarla en el modelo general del proyecto.**
20
21
Los requisitos pueden relacionarse con tareas, documentos, decisiones y otros elementos de ingeniería, manteniendo esas conexiones dentro del mismo entorno.
22
23
La diferencia no está sólo en dónde se escribe el requisito.
24
25
Está en **qué información puede mantenerse conectada a su alrededor y cómo puede utilizarse después**.
26
27
---
28
29
## Cada requisito tiene una historia
30
31
Un requisito rara vez aparece de la nada.
32
33
Puede proceder de una necesidad del usuario, una norma, una decisión de diseño, una restricción de otro subsistema o una conclusión obtenida durante el desarrollo.
34
35
Un gestor de requisitos debe permitir conservar esas relaciones.
36
37
**cosmoSys-Req permite además navegar por ellas como parte del modelo del proyecto.**
38
39
Puedes derivar requisitos, relacionarlos con otros requisitos, asociarlos a documentos y mantener información sobre cómo deben verificarse. Así, cuando alguien pregunta:
40
41
> ¿Por qué tenemos este requisito?
42
43
la respuesta puede estar dentro del propio proyecto.
44
45
Y cuando alguien pregunta:
46
47
> ¿Qué se ve afectado si lo cambiamos?
48
49
las relaciones del modelo pueden ayudar a encontrar la respuesta.
50
51
---
52
53
## Ver el proyecto antes de leerlo entero
54
55
Los proyectos complejos son difíciles de comprender cuando sólo se presentan como listas.
56
57
**cosmoSys genera diagramas directamente a partir de la información real del proyecto.** Las jerarquías, dependencias y relaciones pueden verse gráficamente y utilizarse para explorar el modelo.
58
59
No son dibujos que alguien tenga que mantener aparte.
60
61
**El diagrama nace del modelo.**
62
63
Por eso puede utilizarse para comprender el proyecto mientras se trabaja y también incorporarse después a la documentación que se entrega.
64
65
---
66
67
## Trabajar juntos sobre la misma información
68
69
La colaboración sobre requisitos no es una idea exclusiva de cosmoSys. Las herramientas de gestión de requisitos permiten que distintas personas participen en la definición, revisión y seguimiento de una especificación.
70
71
**cosmoSys-Req lo hace dentro de una aplicación web colaborativa**, donde las personas que participan en el proyecto pueden trabajar sobre la misma información, con roles, permisos y workflows adaptados al proceso de la organización.
72
73
La revisión deja de depender exclusivamente de intercambiar documentos.
74
75
El equipo puede trabajar sobre la especificación, discutirla, derivarla, revisarla y seguir sus relaciones dentro del mismo entorno.
76
77
---
78
79
## La documentación se genera desde lo que realmente existe
80
81
Los gestores de requisitos pueden generar documentos y exportaciones de la información que contienen.
82
83
**cosmoSys-Req pone especial énfasis en la calidad de esa documentación.**
84
85
La información del proyecto puede transformarse en documentos estructurados que incluyen jerarquías, metadatos, referencias y diagramas, utilizando plantillas adaptables a las necesidades de cada organización.
86
87
Los diagramas generados por cosmoSys pueden formar parte de esos documentos, de manera que la documentación represente realmente el modelo que el equipo está utilizando.
88
89
El documento deja de ser una segunda fuente de información que alguien tiene que mantener manualmente.
90
91
**Es una representación del proyecto que puede generarse cuando se necesita.**
92
93
---
94
95
## Las referencias también tienen contexto
96
97
En ingeniería no basta con saber que un documento existe.
98
99
Hay que saber **por qué se cita**, qué parte resulta aplicable y dónde se encuentra la información relevante.
100
101
Los gestores de requisitos pueden mantener referencias hacia documentación externa.
102
103
**cosmoSys añade contexto a esas referencias**, permitiendo relacionar documentos con elementos concretos del proyecto y conservar información sobre el documento, su versión, su localización y el sentido de la relación.
104
105
Así, un mismo documento puede utilizarse en distintos lugares sin perder el motivo concreto por el que se cita en cada uno.
106
107
---
108
109
## Variables, modelos y otra información de ingeniería
110
111
Un proyecto de ingeniería no está compuesto únicamente por requisitos.
112
113
Hay valores, parámetros, restricciones, decisiones, componentes, documentos y otros tipos de información que pueden ser relevantes para comprender el sistema.
114
115
**cosmoSys permite incorporar esta información al modelo del proyecto mediante variables y elementos configurables**, evitando que determinados datos tengan que quedar aislados en documentos o herramientas independientes.
116
117
Esto permite utilizar la misma infraestructura de información para representar diferentes aspectos de un proyecto, según las necesidades de cada organización.
118
119
---
120
121
## Y el proyecto sigue siendo tuyo
122
123
cosmoSys-Req está construido sobre **software libre** y utiliza mecanismos y formatos abiertos para facilitar el intercambio de información.
124
125
No hay licencias por usuario que limiten quién puede participar en el proyecto.
126
127
No hay una suscripción que determine si puedes seguir utilizando la herramienta.
128
129
**Puedes instalar cosmoSys, estudiar su funcionamiento, adaptarlo e integrarlo con otros sistemas.**
130
131
La API facilita la interoperabilidad y la información del proyecto puede exportarse para ser procesada mediante otras herramientas.
132
133
Tus requisitos son conocimiento de tu organización.
134
135
**La herramienta debe ayudarte a gestionarlos, no convertirse en su propietario.**
136
137
---
138
139
## No necesitas cambiar toda tu forma de trabajar
140
141
cosmoSys-Req no pretende obligar a todos los equipos a trabajar exactamente igual.
142
143
**cosmoSys permite configurar proyectos mediante perfiles, campos, roles, permisos y workflows**, de manera que la misma base pueda utilizarse para procesos con necesidades diferentes.
144
145
También puede convivir con otras herramientas.
146
147
La interoperabilidad no es un añadido posterior: forma parte de la idea de mantener el conocimiento bajo el control del equipo.
148
149
---
150
151
## Un ejemplo sencillo
152
153
Imagina que un equipo está desarrollando un instrumento.
154
155
Al principio existe una necesidad:
156
157
**el instrumento debe poder operar dentro de determinadas condiciones.**
158
159
De esa necesidad se derivan requisitos de sistema. Algunos pasan a ser responsabilidad de óptica, otros de mecánica, electrónica o software. Aparecen documentos aplicables y decisiones de diseño. Cada requisito necesita finalmente una forma de comprobar que se cumple.
160
161
Esta es precisamente la clase de información que debe poder gestionar una herramienta de requisitos.
162
163
**cosmoSys-Req permite además mantener estas relaciones dentro del modelo del proyecto:**
164
165
**necesidad → requisito → derivación → diseño → documento → verificación**
166
167
No se trata de que cosmoSys haga la ingeniería por el equipo.
168
169
Se trata de que **el equipo pueda hacer ingeniería sin perder las conexiones que explican lo que está haciendo**.
170
171
---
172
173
## Cuando el proyecto cambia
174
175
Los proyectos cambian.
176
177
Cambian los requisitos, aparecen nuevas restricciones, se descubren errores, se sustituyen componentes y se toman decisiones que afectan a otras partes del sistema.
178
179
El valor de mantener un modelo conectado aparece precisamente entonces.
180
181
**En cosmoSys-Req, las relaciones que se han construido durante el trabajo permanecen disponibles cuando el proyecto evoluciona.**
182
183
Un cambio no es sólo editar una frase: puede utilizarse la información relacionada para descubrir qué más debe revisarse.
184
185
Y cuando el proyecto continúa en manos de otro equipo o de otra persona, las relaciones siguen formando parte del conocimiento del proyecto.
186
187
---
188
189
## Abierto, gratuito y preparado para crecer
190
191
cosmoSys nació con una idea sencilla: las capacidades de ingeniería que una organización necesita para desarrollar sistemas complejos no deberían quedar reservadas a quienes pueden pagar determinadas licencias.
192
193
Por eso **cosmoSys es software libre, abierto y gratuito**.
194
195
Puedes utilizarlo, estudiarlo, adaptarlo e integrarlo con otras herramientas. Puedes mantener el control de tus datos y, si algún día decides utilizar otra solución, puedes llevártelos contigo.
196
197
**No tienes que confiar en nosotros para conservar tu propio conocimiento.**
198
199
---
200
201
# Empieza por el problema que quieres resolver
202
203
cosmoSys-Req tiene muchas funciones, pero no necesitas conocerlas todas para empezar.
204
205
Si tu equipo necesita:
206
207
* gestionar requisitos de forma estructurada;
208
* mantener la trazabilidad entre necesidades, requisitos y otros elementos;
209
* visualizar las relaciones del proyecto mediante diagramas generados desde el modelo;
210
* trabajar sobre una especificación compartida;
211
* generar documentación de ingeniería a partir de la información real del proyecto;
212
* conservar el contexto de las referencias documentales;
213
* incorporar variables y otra información al modelo;
214
* trabajar con una herramienta libre, abierta y gratuita;
215
* o simplemente disponer de una alternativa abierta a las herramientas comerciales de gestión de requisitos,
216
217
**cosmoSys-Req puede ser un punto de partida.**
218
219
[Ver una demostración](#) · [Instalar cosmoSys-Req](#) · [Leer la documentación](#)