11.1 Requirement Element Definition, ID, Text & Compartments

11.1 Requirement Element Definition, ID, Text & Compartments

Quick Reference: In SysML v1.2, a Requirement is a first-class model classifier that bridges text-based specifications and the structural/behavioral system architecture. Graphically rendered as a sharp-cornered rectangle stereotyped with «requirement», its standard definition requires two core properties: id: String (a unique identifier) and text: String (the formal requirement statement). The diagram frame header follows req [Package] ContextName [diagramName].

---

The Evolution of Requirements in Systems Engineering

Historically, systems engineering managed stakeholder requirements in standalone, document-centric environments: multi-hundred-page Word documents, isolated spreadsheets, or dedicated requirements management databases (e.g., IBM DOORS). In these document-centric workflows, requirements existed in complete isolation from the engineering models describing system structure, behavior, and physics.

The Document-Centric Disconnect

• Static Disconnect: Textual requirements could not directly link to the functional actions or physical components meant to fulfill them.
• Traceability Decay: When design changes occurred in CAD or software architectures, verifying that every requirement remained satisfied required tedious, manual spreadsheet audits prone to human error.
• Ambiguity: Prose statements frequently contained conflicting terminology that could not be verified against formal system definitions.

The MBSE Approach: Requirements as First-Class Model Elements

SysML elevates requirements to first-class model elements. In Model-Based Systems Engineering (MBSE), a requirement is not merely external documentation—it is an active semantic entity within the unified model repository.

Integrating requirements directly into the system model delivers three crucial engineering capabilities:

1. Direct Architectural Traceability: Requirements link directly to structural Blocks (via «satisfy»), behavioral activities (via «refine»), test cases (via «verify»), and source requirements (via «deriveReqt»).
2. Impact Analysis: If an operational requirement changes, automated model queries immediately identify every impacted subsystem block, software component, interface port, and verification test case.
3. Single Source of Truth: A requirement exists once in the model repository. It can be rendered across multiple Requirement Diagrams (req), Block Definition Diagrams (bdd), tabular matrices, or external document exports without redundant duplication.

---

Requirement Diagram (req) Syntax & Header Grammar

A Requirement Diagram (req) visualizes requirement elements, their internal properties, and their relationships to other requirements or design artifacts. SysML 1.2 limits what it may display to "requirements, packages, other classifiers, test cases, and rationale," and the relationships it may show to containment, deriveReqt, satisfy, verify, refine, copy, and trace. Like all SysML diagrams, a Requirement Diagram is enclosed in a standard rectangular border with a distinct header block in the upper-left corner.

Diagram Header Syntax

req [type] name [diagramName]

• req: The mandatory, canonical 3-letter lowercase mnemonic for Requirement Diagrams.
• [type]: The metaclass of the enclosing model namespace owning the diagram, typically [Package], [Requirement], or [Model].
• name: The identifier of the specific model element that owns the diagram view (e.g., AvionicsRequirementsPkg).
• [diagramName]: An optional, user-assigned descriptive title providing engineering context (e.g., [Braking Subsystem Traceability]).

Example Headers

• req [Package] PropulsionReqs [Thrust and ISP Allocation]
• req [Requirement] CabinPressurization [Sub-Requirement Decomposition]
• req [Model] SpacecraftSystem [Top-Level Stakeholder Requirements]

---

Visual Anatomy of the Requirement Element

In the SysML metamodel, the Requirement construct is defined as a specialized stereotype that extends the UML Class metaclass. Because it represents a classifier, it shares the graphical appearance of a class-like box.

Graphical Geometry: Sharp Corners

A requirement is drawn as a solid rectangular box with sharp, 90-degree corners. Modeler candidates must distinguish this visual geometry from other SysML constructs:

• Sharp rectangular corners: Blocks, Classes, Packages, and Requirements.
• Rounded corners: States in State Machine Diagrams (stm) and actions in Activity Diagrams (act).
• Ovals: Use cases in Use Case Diagrams (uc).

+-------------------------------------------------------+
|                    «requirement»                      |
|                  BrakingResponseTime                  |
+-------------------------------------------------------+
| id = "REQ-BRK-042"                                    |
| text = "The braking subsystem shall engage friction   |
|         calipers within 150 milliseconds of pedal     |
|         sensor threshold transition."                 |
+-------------------------------------------------------+
| risk = High                                           |
| verifyMethod = Test                                   |
+-------------------------------------------------------+

Standard Requirement Compartments

A requirement box is organized into horizontal compartments separated by thin solid lines:

1. Header (Name) Compartment:
   • Contains the stereotype keyword «requirement» enclosed in guillemets (or a specialized stereotype name such as «performanceRequirement»).
   • Displays the user-assigned Name of the requirement element (e.g., BrakingResponseTime). The name is a concise, title-like noun phrase identifying the requirement within the model namespace.
2. Properties Compartment (ID and Text):
   • Lists the two standard, built-in properties defined by the SysML Requirement stereotype (the «requirement» label on this compartment may be elided):
     • id: String: A unique alphanumeric identifier used for formal tracking, configuration management, and external database cross-referencing (e.g., id = "REQ-BRK-042").
     • text: String: The precise, normative natural-language statement of the requirement (e.g., text = "The vehicle shall..."). In systems engineering practice, this statement typically employs normative modal verbs such as "shall".
3. User-Defined / Custom Compartments:
   • SysML allows modelers and organizations to extend the base requirement stereotype with domain-specific tagged values, displayed in additional named compartments:
     • risk: Qualitative risk level (e.g., High, Medium, Low).
     • verifyMethod: Standard verification approach (e.g., Analysis, Demonstration, Inspection, Test).
     • status: Lifecycle maturity (e.g., Draft, Approved, Rejected, Obsolete).
     • priority: Implementation urgency (e.g., 1, 2, 3).
4. Relationship Compartments:
   • When relationships are not drawn graphically as dashed arrows, a requirement box can list related elements directly in specialized relationship compartments:
     • derived: Subordinate requirements derived from this requirement.
     • derivedFrom: Higher-level source requirements.
     • satisfiedBy: Structural blocks or behaviors fulfilling this requirement.
     • verifiedBy: Test cases proving compliance.
     • refinedBy: Use cases or behaviors elaborating the requirement.
     • tracedTo: Related audit artifacts.

---

Example Requirement Stereotypes (Non-Normative Annex C)

SysML 1.2 does not make requirement categories part of the normative language. Its non-normative Annex C gives an example profile for organizations to adapt: an «extendedRequirement» mix-in that adds source, risk, and verifyMethod properties, and five category stereotypes built on it:

Each category stereotype inherits the standard id and text properties from «requirement» while clarifying the technical nature of the requirement. The Annex also suggests constraints, such as a performance requirement being satisfied by a value property, and says the default category should remain the generic «requirement».

Rules That Come With Being a Requirement

Because «requirement» stereotypes UML Class, SysML 1.2 adds constraints: a requirement owns no attributes or operations of its own (id and text are stereotype properties), it may not participate in associations or generalizations, and any classifier nested inside it must also be a requirement.

---

Tabular Representations: Requirement Tables and Matrices

While graphical Requirement Diagrams (req) are ideal for visualizing relational trees and cross-cutting allocations, large systems engineering projects manage thousands of individual requirements. Reviewing thousands of graphical boxes on a canvas is unwieldy.

SysML formally accommodates this through Requirement Tables and Requirement Matrices:

• Requirement Table: A spreadsheet-like view where each row corresponds to a single requirement element in the model repository, and columns display its properties (id, Name, text, verifyMethod, status). Editing a cell in a requirement table directly updates the model element in the repository.
• Allocation Matrix (Traceability Matrix): A two-dimensional grid where rows represent requirements and columns represent architectural model elements (such as Blocks or TestCases). Cells indicate relationships (such as «satisfy» or «verify»). Modifying a cell in the matrix instantly updates the corresponding relationship in the system model.

---

Worked Example: Autonomous Rover Requirement Hierarchy

Consider the definition of requirements for an autonomous planetary exploration rover:

1. «requirement» SystemRange
   • id = "REQ-SYS-001"
   • text = "The exploration rover shall travel a minimum distance of 500 meters per operational sol."
2. «performanceRequirement» PowerBudget
   • id = "REQ-PWR-010"
   • text = "The solar array subsystem shall generate at least 450 W-hr of electrical energy per sol under nominal atmospheric opacity."
3. «physicalRequirement» ChassisMass
   • id = "REQ-STR-020"
   • text = "The structural chassis mass shall not exceed 45.0 kg."
4. «designConstraint» BatteryChemistry
   • id = "REQ-DES-005"
   • text = "The energy storage system shall utilize space-qualified Lithium Iron Phosphate (LiFePO4) cell chemistry."

Each requirement maintains an explicit identifier, unambiguous normative text, and correct classification under the SysML stereotype hierarchy.

---

Exam Pitfalls & Misconceptions