> For the complete documentation index, see [llms.txt](https://docs.violetlabs.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.violetlabs.com/es/funciones/requisitos/mejores-practicas.md).
# Mejores prácticas
### Organizar sus Requisitos
Hay una variedad de métodos para organizar sus requisitos en Violet; elija la opción que mejor se alinee con sus enfoques actuales. Tenga en cuenta:
* Los requisitos hijos se crean mediante anidamiento jerárquico en Violet
* Puede asociar varios sistemas con un solo requisito (un requisito podría tratar sobre la matriz solar, involucrando tanto subsistemas eléctricos como mecánicos)
* Hay dos vistas tabulares de requisitos entre las que puede alternar fácilmente: una organizada por la jerarquía de requisitos y la otra organizada por el sistema asignado (ver [Estructura](/es/funciones/requisitos/estructura.md)). Use [Vistas de Gráfico o Documento](/es/funciones/requisitos/vistas.md) para inspeccionar los requisitos, también.
#### (Recomendado) Use Requisitos como Requisitos
En este enfoque, los requisitos se descomponen directamente en sus hijos en el siguiente nivel. El nivel superior de requisitos son las especificaciones de alto nivel.
Los beneficios de esta estrategia incluyen:
* Relaciones claras entre padre/hijo
* Cada elemento en cada vista es un requisito; sin información extránea
Los inconvenientes de esta estrategia incluyen:
* La vista tradicional de “árbol de especificaciones” no es fácilmente discernible (solución alternativa: use la vista “sistema” para agrupar la tabla de requisitos por sistema asociado, aproximando un árbol de especificaciones)
* Menor oportunidad para proporcionar información de apoyo que pueda relacionarse con múltiples requisitos (solución alternativa: los atributos personalizados pueden habilitar información específica del requisito)
#### Use Objetos de Requisito como Especificaciones y Encabezados
En este enfoque, los objetos de requisito actúan como requisitos (declaraciones "shall" que necesitan verificación), especificaciones (una colección de requisitos sobre un tema similar), encabezados de sección (grupos más pequeños de requisitos) y texto descriptivo.
Los beneficios de esta estrategia incluyen:
* Se asemeja a una vista de requisitos más tradicional basada en documentos
* Proporciona un medio para añadir contexto adicional a los requisitos, como introducciones
Los inconvenientes de esta estrategia incluyen:
* Difícil distinguir fácilmente los requisitos que deben verificarse de la información de apoyo u organización (que también son objetos de requisito)
* Elementos adicionales en algunas vistas tabulares
#### Agrupar Requisitos dentro de Carpetas
Esta opción de organización utiliza una carpeta para cada especificación (conjunto o colección de requisitos para una parte dada del sistema, ICD, especificaciones de prueba, normas de la empresa relevantes, etc.).
Agregue una descripción de la carpeta para aclarar el alcance del contenido en esa carpeta o añada texto introductorio. Anide carpetas para agrupar y ordenar requisitos en un esquema útil; puede reordenar el esquema con el botón "Habilitar Organizar".
Los beneficios de esta estrategia incluyen:
* Se asemeja a una vista de esquema más tradicional basada en documentos
* Distingue fácilmente los requisitos que deben verificarse de la información de apoyo u organización
Los inconvenientes de esta estrategia incluyen:
* Pérdida de descomposición padre-hijo (los requisitos de nivel superior en una carpeta separada de los requisitos de nivel inferior (derivados) en otra carpeta no están vinculados con una relación padre/hijo, porque padre/hijo se expresa mediante anidamiento en Violet)
* Elementos adicionales (carpetas) visibles en algunas vistas tabulares y gráficas
### Otras Recomendaciones
Considere usar [Parámetros](/es/funciones/parametros.md) para almacenar hechos y contexto sobre la misión, el sistema o el diseño que no son necesariamente requisitos que deban verificarse. Estos parámetros pueden vincularse a [Scripts](/es/funciones/scripts.md) y análisis que referencien ese hecho como una variable de entrada.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.violetlabs.com/es/funciones/requisitos/mejores-practicas.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.