Requirement diagram
A requirement diagram provides a visualization of requirements and their connections to each other, as well as their relationships to other documented elements.
Copy
Embed
requirementDiagram
requirement test_req {
id: 1
text: the test text.
risk: high
verifymethod: test
}
element test_entity {
type: simulation
}
test_entity - satisfies -> test_req
Syntax
A requirement diagram contains three kinds of components: requirements, elements, and relationships.
Words shown in angle brackets are enumeration keywords, such as , whose options are detailed in the table. user_defined... is used wherever user input is required.
Important note about user text: all input can be enclosed in double quotes or left without them. However, users must be careful when using unquoted input. If other keywords are detected, the editor will fail to render.
Requirement
A requirement definition contains the requirement type, name, ID, text, risk, and verification method. The syntax is as follows:
Copy
Embed
<type> user_defined_name {
id: user_defined_id
text: user_defined text
risk: <risk>
verifymethod: <method>
}
Type, risk, and method are enumerations defined in SysML.
| Keyword | Options |
|---|---|
| Type | Requirement, Functional Requirement, Interface Requirement, Performance Requirement, Physical Requirement, Design Constraint |
| Risk | Low, Medium, High |
| Verification method | Analysis, Inspection, Test, Demonstration |
Element
An element definition contains an element name, type, and document reference, all three of which are user-defined. The element feature is designed to remain lightweight while allowing requirements to be associated with parts of other documents.
Copy
Embed
element myElement {
type: string
docref: some/doc/path
}
Markdown format
Where user-defined text is allowed (such as names, requirement text, element document references, etc.), you can:
- Enclose the text in double quotes
- Use markdown format within the double quotes
Copy
Embed
requirementDiagram
requirement "__test_req__" {
id: 1
text: "*italicized text* **bold text**"
risk: high
verifymethod: test
}
Relationship
A relationship consists of a source node, a target node, and a relationship type.
Follow the following definition format:
Copy
Embed
{name of source} - <type> -> {name of destination}
Or
Copy
Embed
{name of destination} <- <type> - {name of source}
"Source node" and "target node" should be the names of requirement or element nodes defined elsewhere.
The relationship type can be one of contains, copies, derives, satisfies, verifies, refines, or traces.
Detailed example
This example uses all the features of this diagram.
Copy
Embed
requirementDiagram
requirement test_req {
id: 1
text: the test text.
risk: high
verifymethod: test
}
functionalRequirement test_req2 {
id: 1.1
text: the second test text.
risk: low
verifymethod: inspection
}
performanceRequirement test_req3 {
id: 1.2
text: the third test text.
risk: medium
verifymethod: demonstration
}
interfaceRequirement test_req4 {
id: 1.2.1
text: the fourth test text.
risk: medium
verifymethod: analysis
}
physicalRequirement test_req5 {
id: 1.2.2
text: the fifth test text.
risk: medium
verifymethod: analysis
}
designConstraint test_req6 {
id: 1.2.3
text: the sixth test text.
risk: medium
verifymethod: analysis
}
element test_entity {
type: simulation
}
element test_entity2 {
type: word doc
docRef: reqs/test_entity
}
element test_entity3 {
type: "test suite"
docRef: github.com/all_the_tests
}
test_entity - satisfies -> test_req2
test_req - traces -> test_req2
test_req - contains -> test_req3
test_req3 - contains -> test_req4
test_req4 - derives -> test_req5
test_req5 - refines -> test_req6
test_entity3 - verifies -> test_req5
test_req <- copies - test_entity2
Direction
You can use the direction statement to render the diagram in different directions; the valid values are:
- TB - Top to bottom (default)
- BT - Bottom to top
- LR - Left to right
- RL - Right to left
Copy
Embed
requirementDiagram
direction LR
requirement test_req {
id: 1
text: the test text.
risk: high
verifymethod: test
}
element test_entity {
type: simulation
}
test_entity - satisfies -> test_req
Styles
Requirements and elements can be styled using direct styles or classes. In general, when applying a style or class, it accepts a list of requirement or element names and a list of class names, allowing multiple classes to be assigned at once. The only exception is the shorthand syntax :::, where the operator can assign multiple classes but only to one requirement or element at a time.
Direct style
Copy
Embed
requirementDiagram
requirement test_req {
id: 1
text: styling example
risk: low
verifymethod: test
}
element test_entity {
type: simulation
}
style test_req fill:#ffa,stroke:#000, color: green
style test_entity fill:pink,stroke:#333, color: blue
A class is defined as shown in the following example:
Use classDef to define reusable styles:
Copy
Embed
requirementDiagram
requirement test_req {
id: 1
text: "class styling example"
risk: low
verifymethod: test
}
element test_entity {
type: simulation
}
classDef important fill:#f96,stroke:#333,stroke-width:4px
classDef test fill:#ffa,stroke:#000
Default class
If a class is named default, it will be applied to all nodes. Specific styles and classes should be defined after this to override the default style that has been applied.
Copy
Embed
classDef default fill:pink,stroke:#333,stroke-width:4px;
Applying a class
Classes can be applied in two ways:
1. Using the class syntax:
Copy
Embed
class test_req,test_entity important
2. Using the operator ::: shorthand syntax during or after the definition:
Copy
Embed
requirement test_req:::important {
id: 1
text: class styling example
risk: low
verifymethod: test
}
Copy
Embed
element test_elem {}
test_elem:::myClass
Combined example
Copy
Embed
requirementDiagram
requirement test_req:::important {
id: 1
text: "class styling example"
risk: low
verifymethod: test
}
element test_entity {
type: simulation
}
classDef important font-weight:bold
class test_entity important
style test_entity fill:pink,stroke:#333
