# Best practices

### 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](https://docs.violetlabs.com/features/requirements/structure "mention")). Use [Graph or Document views](https://docs.violetlabs.com/features/requirements/views) to inspect requirements, as well.

#### (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).

<figure><img src="https://2091741164-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvrraExym8pNEUvBDoima%2Fuploads%2F2BB3XEaiQx7Nv3gp1KJW%2FRequirements%20Nesting%20Example.png?alt=media&#x26;token=49054894-35c4-4450-a876-bb774ddbfaaa" alt=""><figcaption></figcaption></figure>

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.

<figure><img src="https://2091741164-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvrraExym8pNEUvBDoima%2Fuploads%2FH6iRFQLt0N1DVbr7Bez0%2FReqts%20as%20Headings%20and%20Specs%20Example.png?alt=media&#x26;token=f7c8ba5c-31b0-463a-a159-7840e19d2196" alt=""><figcaption></figcaption></figure>

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 within 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.

<figure><img src="https://2091741164-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvrraExym8pNEUvBDoima%2Fuploads%2FwT8PVVPdfU79ZM2dw5OJ%2FRequirements%20with%20folders.png?alt=media&#x26;token=97f03b52-d540-4dac-a9b9-d184e64718e4" alt=""><figcaption></figcaption></figure>

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](https://docs.violetlabs.com/features/parameters "mention") 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](https://docs.violetlabs.com/features/scripts "mention") and analyses that reference that fact as an input variable.