Requirements and Requirement Relationships follow a few basic guidelines:
Requirements are foundational to any system design and represent a Pillar of SysML.
A good requirement is a complete sentence with a single ‘SHALL’.
Characteristics of a Requirement Statement are: Clear and Consistent, Correct, Feasible, Flexible, Un-ambiguous, Singular, and Verifiable.
A requirement is a statement that identifies a product or processes operational, functional, or design characteristic or constraint, which is unambiguous, testable, or measurable and necessary for product or process acceptability.
ISO 2007
Requirement Classes
Requirements also don‘t come in a one size fits all package. They can and should be broken up into logical categories to allow users to understand how they should be related into one‘s architecture. We break requirements into 4 different types but we understand the community breaks them up in all sorts of ways. Here is our cut at requirements types with their definitions:
Functional Requirement
This is by far the most common requirement type and is a cornerstone to any system design. A functional requirement defines what functions a given system (or other fidelity level: subsystem, CI) shall perform to accomplish a given mission or operational objectives.
Interface Requirement
Defines how a given system interacts or exchanges with another system. These requirements can be categorized by both logical and physical interactions.
Non-Functional Requirement
Non-Functional requirements have a large grouping of categories beneath them and are sometimes referred to as the ‘illities’ (reliability, safety, human factors). They serve a purpose to define a specific criteria used to judge the operation of a system, rather than a specific function. They are in direct contrast with functional requirements which define system behaviors. For the sake of time in our demonstration, we will be showing you how to relate a physical and an environmental non-functional requirement.
Performance Requirement
Defines how well a given system needs to perform to support a functionality.
Requirements and Requirement Relationships
Requirement Relationships
Containment
A containment relationship is mainly used for organizational purposes within your requirements hierarchy. In general terms, it should be used when you want to convey a requirement containing sub-requirements. This is key when organization is important and a given number scheme has been given to requirements and sub requirements. The Requirements will generally follow a decimla numbering pattern like (1, 1.1, 1.1.1). This relation should not be mistaken for parent/child relationships, as a derive relationship should be used for that.
Derive
A derive relationship is used when you would like to convey the next level of system hierarchy for a requirement. For example, when a system requirement is decomposed to subsystem requirements, they should be related via a derive relationship. This relation is used quite frequently when defining the parent child relationship between two requirements. While containment can be used for this purpose, we recommend using derive for all parent child relationships due to its ability to enable reuse of children (modularity). It should be noted that a derive relationship should be used ONLY between requirements. No other model element is applicable for this relationship type.
Verify
The verify relationship defines how a requirement is proven or verified. This is generally shown through the use of test cases within your model architecture.
Trace
A trace relationship is a WEAK relationship and does not have directionality. We have mainly used it for tracing to an artifact library but it can be used for anything that doesn‘t necessarily fit into the categories above. It can serve as a PLACEHOLDER until you find a better way to relate your requirement. Please use the above relationships before considering this relationship.
Pingback: How Can I Manage Requirements in Cameo? - Beyond MBSE
Pingback: Model Organization - Beyond MBSE