Requirements Diagram
Use to be text-based requirements (and requirements specifications in them) traditionally. This can be represented through the requirements diagram (req). It traces requirements to the elements in the system model.
Requirement = rectangle with stereotype <<requirement>> preceding the name and two properties, id and text, both of type string. SysML only requires these two properties, though such properties as rationale, priority, verification method, could be tracked in the Text field. SysML is more concerned about the relationships of the requirements in the model.
Relationships
There are 6 requirement relationships: These help track traceability.
– Containment
– Trace
– Derive requirement
– Refine
– Satisfy
– Verify
– Copy (rarely used)
Containment = package is like namespace that contains other elements in the model hierarchy. Requirements can only contain other requirements. In requirements diagram, use same notations as package diagrams: crosshair notation and qualified name string notation. (no nesting notation because requirements don’t have graphical compartments)
Trace = indicates that modification to the supplier element may impact the client element (in Figure 11.1 the DellSat System Requirement traces back to the Mission Requirements Specifications)
Derive requirement = indicates that the client element requirements derived from supplier, and as such, changes at one level could impact entire chain of derived requirements. This relationship requires that there are requirements on both ends.
Refine = indicates that the requirement at the client element is more concrete (less abstract) than that of the supplier end. Offers clarity at the client end.
Satisfy = assertion that the client end will fulfill the requirement at the supplier end. But this does not constitute proof, as this comes from the test cases. The rule is that the supplier end must have a requirement but no rules for client end but its usually a block.
Verify = states that the client end verifies the supplier end requirement, which is usually done through a test case. So the supplier end must have a requirement and the client end has a test case.
Notations
Directnotation = dependency notation of a dashed line with open arrowhead
Compartmentnotation = using the block compartments for showing the relationships.
Calloutnotation = use of comment anchored to an element
Matrix notation = expresses many relationships in the least amount of space. No formal format defined in SysML so every modeling tool can generate differently.
Table = similar to matrix but it also shows properties of elements (eg id) and the relationships between them. No formal format defined in SysML so every modeling tool can generate differently.
Rationale
SysML only requires ID and TEXT for requirements. Sometimes, a comment like block is used to track rationale.
Allocations: Cross-Cutting Relationships
Allocations = allocating requirements to structures, allocation behaviors to structures, allocating logical structures to physical structures and allocating resources to structures (eg mass, power, cost, throughput). More commonly known as cross-cutting relationships. Can be created between any two model elements, anywhere in the system model. There is no separate allocation diagram. These relationships can be done between any of the nine kinds of SysML diagrams.
Behavioral Allocation
Behavioralallocation = known as functional allocation is the activity of allocating behavioral element to a structural element. Such as:
– Allocating an activity, interaction or state machine back to block
– Allocating an action (in an activity) to a part of a property (owned by a block)
Structural Allocation
Structuralallocation = activity of allocating structural element back to another structural element. Such as:
– Allocating a logical block to a physical block
– Allocating a software property to a hardware property
What the system must do and then later how the system will do it.
Requirements Allocation
Requirementsallocation = allocating requirements to structures (and the most common form of allocation). This is done through the <<satisfy>> relationship in the requirementsdiagram.
Notations
Direct notation = putting strong focus on the allocation relationship itself, as done in Figure 12.1. and 12.2
Compartmentnotation = use where there are elements that can display compartments (blocks, activities, part properties, BDD, IBD) using compartment names of AllocatedTo and AllocatedFrom.
Callout Notation = simply using a comment anchored to an element.
Matrices = traditional medium for expressing relationships, able to hold most information in least amount of space. SysML does not have specifics on this so it depends mostly on the modeling tool used.
Tables = similar to matrices, but can hold some more information (but on the downside, not as compact). SysML also does not have specifics for this so it is mostly based on the modeling tool generating it.
Allocationactivitypartitions = activity partition with <<allocate>> stereotype in the name in the header. Only used on activity diagram and only used to show behavioral allocation.
Rationale = like in the RequirementsDiagram, rationale blocks can be used to explain the allocations. These require <<rationale>> in the name and can be used in any kind of element or relationship in the system model.