Getting Started with Violet Requirements

This page summarizes the steps you can take to set up and begin using Violet's Requirements module.

Setting up Your Team and Program

Invite your Team to the Violet platform to establish their user accounts.

Create user groups and add team members to the groups: these user groups can later be assigned to particular system areas and requirements to control read/write access.

Create a Violet Program

Violet Programs enable granular permissions to Violet Requirements and other features.

Define Systems Elements to Grant Permissions and Express Allocation

Systems elements contribute to user permissions and grouping, filtering and sorting Violet Requirements. User groups or individual users assigned to systems will be able to edit requirements associated with the system; these users are designated requirement owners.

Create Custom Requirements Fields and Relationships

Create Custom Fields or relationships for requirements in the Program(TBD LINK) configuration pane to enable your organization’s unique requirement management approach.

Custom columns could be added to help transition data out of an external tool and Import from CSV into Violet for development going forward, e.g.

Organizing your Requirements

There are a variety of methods to organizing your Violet requirements; choose the option that aligns best to your current approaches. Keep in mind:

• Child requirements are created via hierarchical nesting in Violet

• You can associate multiple systems with a single requirement (a requirement might be about the solar array, involving both electrical and mechanical subsystems)

• There are two tabular views of requirements you can easily toggle between - one organized by requirement hierarchy and the other organized by assigned system (see Structure: Hierarchy vs. System).

(Recommended) Use Requirements as Requirements

In this approach, requirements are decomposed directly into their children at the next level. The top-level of requirements is the top-level specification(s).

Benefits of this strategy include:

• Clear parent/child relationships

• Every element in every view is a requirement; no extraneous information

Drawbacks of this strategy include:

• Traditional “specification tree” view isn’t readily discernible (workaround: use the “system” view to group the requirements table by associated system, approximating a spec tree)

• Reduced opportunity to provide supporting information that might relate to multiple requirements (Workaround: custom attributes can enable requirement-specific info)

Use Requirements Objects as Specifications and Headings

In this approach, requirement objects act as requirements (shall statements needing verification), specifications (a collection of requirements on a similar subject), section headings (smaller groups of requirements), and descriptive text.

Benefits of this strategy include:

• Resembles a more traditional, document-based requirements view

• Provides a means to add additional context to requirements, such as introductions

Drawbacks of this strategy include:

• Challenging to readily distinguish requirements that must be verified from supporting or organizing information (which are also requirements objects)

• Extra elements in some tabular views

Group Requirements with Folders

This organization option utilizes a folder for each specification (set or collection of requirements for a given part of the system, ICD, test specs, relevant company standards, etc.).

Add a folder description to clarify the scope of content in that folder or add introductory text. Nest folders to group and order requirements into a helpful outline; you can reorder the outline with the “Enable Organize” button.

Benefits of this strategy include:

• Resembles a more traditional, document-based outline view

• Easily distinguishes requirements that must be verified from supporting or organizing information

Drawbacks of this strategy include:

• Loss of parent-child decomposition (higher-level requirements in a separate folder from lower-level (derived) requirements in another folder aren’t linked with a parent/child relationship, because parent/child is expressed by nesting in Violet)

• Extra elements (folders) visible in some tabular and graphical views

Other Recommendations

Consider using Parameters to store facts and context about the mission, system or design that aren’t necessarily requirements that must be verified. These parameters can be linked to Scripts and analyses that reference that fact as an input variable.