Primeros pasos
Sigue la guía a continuación para comenzar a crear y gestionar requisitos.
Crear un Programa
Primero, necesitarás crear un Programa.
Programas también habilitar permisos granulares para Requisitos y otras funciones.
Configura tu equipo
A continuación, deberás añadir miembros del equipo, asignar roles y (opcionalmente) crear grupos. Los grupos pueden usarse para otorgar permisos a requisitos o sistemas específicos.
Los usuarios externos (como clientes o socios) pueden añadirse como Invitados. Los invitados pueden ver requisitos y dejar comentarios, pero tienen restricciones para ver otros datos o funciones en Violet.
Definir Sistemas
Sistemas los elementos contribuyen a los permisos de usuario y a la agrupación, filtrado y ordenación de los Requisitos de Violet. Los grupos de usuarios o los usuarios individuales asignados a sistemas podrán editar los requisitos asociados con el sistema; a estos usuarios se les designa como propietarios del requisito.
Crear campos personalizados y relaciones
Crear Campos personalizados o relaciones para requisitos en el Panel de configuración del Programa para habilitar el enfoque único de gestión de requisitos de tu organización.
Se podrían añadir columnas personalizadas para ayudar a trasladar datos desde una herramienta externa y Importación y exportación de requisitos a Violet para el desarrollo de ahora en adelante, p. ej.
Creación de Requisitos
Ver Trabajar con requisitos de Violet
Organización de tus Requisitos
Hay una variedad de métodos para organizar tus requisitos en Violet; elige la opción que mejor se alinee con tus enfoques actuales. Ten en cuenta:
Los requisitos secundarios se crean mediante anidamiento jerárquico en Violet
Puedes asociar múltiples sistemas con un solo requisito (un requisito podría referirse al conjunto solar, involucrando tanto subsistemas eléctricos como mecánicos)
Hay dos vistas tabulares de requisitos entre las que puedes alternar fácilmente: una organizada por jerarquía de requisitos y la otra organizada por sistema asignado (ver Estructura: Jerarquía vs. Sistema). Usa vistas de Gráfico o Documento para inspeccionar los requisitos, también.
(Recomendado) Usa Requisitos como Requisitos
En este enfoque, los requisitos se descomponen directamente en sus hijos en el siguiente nivel. El nivel superior de requisitos es la(s) especificación(es) de nivel superior.

Los beneficios de esta estrategia incluyen:
Relaciones claras padre/hijo
Cada elemento en cada vista es un requisito; no hay información extraña
Los inconvenientes de esta estrategia incluyen:
La vista tradicional de “árbol de especificaciones” no es fácilmente discernible (solución: usa la vista de “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: los atributos personalizados pueden habilitar información específica del requisito)
Usa Objetos de Requisito como Especificaciones y Encabezados
En este enfoque, los objetos de requisito actúan como requisitos (declaraciones de deberá 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 agregar contexto adicional a los requisitos, como introducciones
Los inconvenientes de esta estrategia incluyen:
Es difícil distinguir con facilidad los requisitos que deben verificarse de la información de apoyo u organización (que también son objetos de requisito)
Elementos extra en algunas vistas tabulares
Agrupa Requisitos con 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 relevantes de la empresa, etc.).
Agrega una descripción de la carpeta para aclarar el alcance del contenido en esa carpeta o añade texto introductorio. Anida carpetas para agrupar y ordenar requisitos en un esquema útil; puedes 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 la 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 por una relación padre/hijo, porque padre/hijo se expresa mediante el anidamiento en Violet)
Elementos extra (carpetas) visibles en algunas vistas tabulares y gráficas
Otras recomendaciones
Considera usar Parámetros 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 y análisis que referencien ese hecho como una variable de entrada.
Última actualización
¿Te fue útil?

