Requirement Fields

In the context of this documentation “Valispace“ will be called “Requirements and Systems Portal“.

The Requirements Module has different columns for every Requirement Field, each with its characteristics. However, if a field is unavailable for your use case, you can create a custom column in the custom columns page within the settings. Figure Default Requirement Fields (2) illustrates one way to set the visibility for each of these columns via the “Columns” side pane (1).

Users can also set which columns are visible through the header pop-up panel (3) as see in Figure Header Pop-Up Panel, by clicking on the three dash line which appears when hovering the mouse over any of the columns headers (1), and clicking on the columns tab (3).

Column Fields	Characteristics
Identifier	The identifier is the mandatory field, usually a unique name to the requirements. For example, in BAT-001, the BAT represents the abbreviation of the battery subsystem, and 001 represents the first requirement of the subsystem.
ID	ID is different from the identifier in the Requirements and Systems Portal. The software automatically creates IDs when a requirement is created. IDs are used in the Backend and also in the Rest API.
Title	As the name suggests, it is a title or a short description of the requirement.
Text	This field contains the requirement text. You can use the dollar sign to directly reference Valis, Blocks, and other Requirements in this field.
Rationale/comment	The user can input additional comments or the logical reasons behind the requirement in this field.
Specification	This field shows the name of the specification to which the requirement belongs. It’s a drop-down menu, and if the user wants to move from one specification to another, he can select the specification, and it will automatically move.
Images	If your requirement requires additional information in the form of an image, the user can add it here.
Section	Similar to specification, this field shows the name of the section in which the requirement belongs. It’s a drop-down menu, and if the user wants to move from one section to another, the user can select the section and the Requirements and Systems Portal automatically rearranges the requirement.
Path to Section	If a requirement is placed within a sub-section, its full path will be displayed here, with each section level being separated by a “\” character. This field can be used in an imported file to create the section structure and properly place the requirements on creation.
Parents	If the requirement has a parent’s requirements, it shows the list of requirements which are a parent. Clicking on them leads to information on the parents' requirements.
Children	If the requirement has children’s requirements, it shows a list of requirements. Clicking on them leads to information about children’s requirements.
Type	It is a user-defined field. The type relates to what kind of requirement it is. For example, our default ones are functional, performance and system. Users can add other option fields. Refer toRequirements Settings.
Verified children	This field shows which children are verified.
State	This field shows the state of the requirement identifier and the text. The current defaults are final, draft, and in review. You can set the transition settings in the state. So, whenever the requirement text or identifier is edited, the state is automatically changed. Refer toRequirements Settings.
Verification status	Here you can find if the requirement is verified or not.
Verification methods	The method by which you are verifying the requirements. Currently, we have Analysis, Inspection, Review, Rules, and Tests. Users can add additional verification methods based on their use case. Refer toRequirements Settings.
Blocks	In the Requirements and Systems Portal, each requirement is related to blocks and the verification is done for each block. The verification method is editable only when the block is referred to as a requirement.
Compliance	Add the nature of compliance with the requirement. Default ones are compliant, partially compliant and non-compliant.
Compliance comment	If you have any comments related to the compliance, they can be added here.
Closeout reference	The supporting information that proves the verification method. Refer toVerifications within the Requirements and Systems Portal.
Attachments	Attach any documents related to the requirements/verification document.
Verified on	The latest date on which it was verified.
Verified by	Shows the name of the user who verified the requirement.
Owner	Displays the owner of the requirement.
Tags	If the user wants to group based on special needs e.g. to be reviewed, the user can add tags to each requirement.
Position	You cannot have a custom arrangement of requirements as it is sorted alphabetically. So, to have a workaround, a position was introduced. Give a number to each number according to your order and sort the column to have the custom order.
Created	The date on which the requirement was created.
Updated	The date on which the requirement was last updated.
Custom fields	If the user needs a field that does not cover his use case, he can create custom fields, which can be rich text fields or drop-down menus.