Requirements on an interface

[johnafitch]

How can requirements be associated with an interface through the Interconnection View user interface? Do you have an example that distinguishes between the requirements on an interface and the requirements on the ports at either end?

In my simple example, I want to specify the characteristics of the interface (capacity, quality metrics or timeliness) that passes various types of data or work products between two parts.

[AxelRICHARD]

Hello,

We don't handle Requirements in the Interconnection View yet.
But It should be possible with General View.
How your Requirements are linked with your Interfaces in your model ?

Regards,

[johnafitch]

In traditional language, I would generally say that Requirements specify, i.e., define or constrain the characteristics of an Interface between 2 systems/parts.

When performing a Context Analysis at the start of a project, I want to clarify the system boundary by identifying, naming and eventually characterizing (defining requirements for) each interface between my system of interest and any external actor (human, engineered system or natural world). This includes planned interfaces/interactions and unplanned and even undesirable ones, e.g., adversaries, hackers or other failed systems. I want to name and connect an interface between the system of interest (a Part in the larger context) and the external actor/part, ideally without creating Ports to keep it simple at this point. Then attach to the Interface node a set of requirements that address physical geometries, flow transfer capacities, item flow (what is being passed across the interface), noise added/attenuation loss across the interface, etc. I would like to do that early in the project without doing much interface design, i.e., turning each external interface into a physical part. I would like to generate a specification that summarizes the requirements for each interface so that I can define the requirements on the system of interest to support each external interaction.

[johnafitch]

As I have been reading through the SysML v2 language specification (sections 7.13 & 7.14), I realized that an Interface is a more restrictive and specialized type of Connection. For the Context Analysis example, dropping back to the more generalized connection types (e.g., with or without flow) might be the better modeling mechanism for abstracting how a System of Interest relates to the outside world and associating requirements with each pair of real world things (System of Interest = a part; external actor = a part; both composite elements within a higher-level context (also modeled as a part). I'll do some experimenting with this to clarify when an Interface makes sense vs the more generalized connection types. Perhaps hanging requirements on generalized connections makes more sense until detailed physical design defines the ports on each part.

[AxelRICHARD]

Could you share here a small textual model containing what you want to achieve please?