arXiv:2604.19390v1 [cs.SE] 21 Apr 2026
Towards Formalising Stakeholder Context using SysML v2 Matthew Harrison Loughborough University Epinal Way Loughborough, Leicestershire, LE11 3TU [email protected]
John Carlin Nuclear Waste Services Pelham House, Pelham Drive Calderbridge, Cumbria, CA20 1DB john.carlin@ nuclearwasteservices.uk
Sarah Dunnett Loughborough University Epinal Way Loughborough, Leicestershire, LE11 3TU [email protected]
Siyuan Ji Loughborough University Epinal Way Loughborough, Leicestershire, LE11 3TU [email protected]
Copyright © 2026 by the author(s). Permission granted to INCOSE to publish and use.
Abstract This paper presents a framework to bridge the gap between subjective stakeholder context and formal system architecture. This is achieved using Soft Systems Methodology (SSM) and Systems Modelling Language version 2 (SysML v2). The methodology utilises the precision of Kernel Modelling Language (KerML) and the alignment of SysML v2 with ISO 42010 to define a reference architecture for the mapping of SSM outputs to SysML v2 concepts such as stakeholders and concerns. Application of the framework is demonstrated through the use of a case study, highlighting the traceable path from stakeholder context to system architecture. The structured mapping and increased semantic precision of SysML v2 are anticipated to reduce the risk of misinterpretation compared to less formal approaches, though empirical validation across diverse stakeholder contexts remains as future work. The primary identified tradeoff is the increased barrier to entry associated with SysML v2’s textual notation.
Chengyuan Liu Loughborough University Epinal Way Loughborough, Leicestershire, LE11 3TU [email protected]
Keywords MBSE, SysML v2, Soft Systems Methodology, ISO 42010, Stakeholder Context.
1. Introduction Soft Systems Methodology (SSM) has long been used by engineers to make sense of complex systems, where objectives may be interdisciplinary, unclear or conflicting (Checkland, 1981). By framing the requirements of a complex system using the viewpoints of the stakeholders involved, SSM creates models that capture system context, which is often missing from hard systems engineering methodologies such as Model-Based Systems Engineering (MBSE). A common and long-standing criticism of MBSE is that, by applying strict logic to ambiguous requirements, the wrong problem is solved effectively (Mitroff and Featheringham, 1974). While SSM excels at providing context, there remains the need for a formal language to define the resulting system architecture. Historically, the language of choice has been Systems Modelling Language (SysML), an extension of the Unified Modelling Language (UML). However, the software-centric UML 1
was never fully suited to the modelling of physical systems. This disconnect, combined with an ambiguous standard (Amissah et al., 2018), can lead to an uneven implementation and lack of precision (Salado and Wach, 2019). This is mitigated using frameworks such as Unified Architecture Framework (UAF) (Object Management Group, 2022) to define highlevel relationships, although this lacks a procedure for the transition to modelling. Leaving the translation of the high-level stakeholder needs into executable models at the discretion of the individual risks inconsistency between the framework and the implementation (Morkevicius et al., 2021).
The relevant elements of SSM and SysML v2 and their alignment are described, using ISO 42010 (International Organization for Standardization et al., 2022) as an intermediary. This is formalised using a reference architecture (Harrison, 2025), the application of which is demonstrated using a generic case study, detailing the transition from stakeholder context to a system architecture in SysML v2.
Prior applications of SSM using SysML have successfully used conceptual models as the basis for both UML (Bustard et al., 1999) and SysML (Cloutier et al., 2015) models, providing a starting point to toplevel system architecture. However, the suitability of SysML’s semantic structure to capture the conclusions of the conceptual models was questioned, with the enforcement of semantic discipline highlighted as a possible disincentive to using this combination.
The overall process proposed by Checkland (Checkland, 1981) is shown in Figure 1. It is noted that this framework will be familiar to many, as reflected by the age of the citations, but for the sake of context, the areas which are relevant to the proposed framework (1-5) are summarised.
SysML version 2 (SysML v2) addresses the root of this problem by introducing a bespoke metalanguage, Kernel Modelling Language (KerML), as well as a textual notation underpinning a more dynamic version of the graphical representation SysML is known for. SysML v2 is still in the early stages of application and the core semantics of KerML are likely to be refined (Almeida et al., 2025). Current research includes investigations into the current state of SysML v2’s semantic capabilities (Litwin et al., 2024) and possible methods of application, such as bespoke profiles (Kausch et al., 2025), new tools which utilise the textual notation (Vaicenavičius et al., 2025), and methods of structuring models to optimize data exchange (Li et al., 2024). A standardised approach for capturing context using SysML v2 concepts remains a significant research gap. Establishing such an approach presents the opportunity to tailor future refinements of KerML and SysML v2 to this specific application. This paper proposes a framework to capture stakeholder context by providing a reference architecture that maps SSM outputs directly to SysML v2 elements, bridging the gap between ambiguous stakeholder needs and rigorous system architecture. This aligns with the ISO 15288 System Architecture Definition process, providing the transition from stakeholder needs to the requirements definition process (International Organization for Standardization et al., 2023).
2. Background 2.1 Soft Systems Methodology
2.1.1 Rich Picture The goal of the rich picture in SSM is to represent a situation from a number of viewpoints using an illustration, allowing for parallel processing of the information therein (Wilson, 2001) without the constraints of a formal language. This process is flexible; a group of stakeholders may create a rich picture together, or a research team may create one based on interviews (Mukotekwa and Carson, 2007), although it has been noted that the latter, while capable of gathering more information, runs the risk of missing key insights (Gisby et al., 2023). If questions are too open, then key insights may be missed, whilst guiding the direction too forcefully risks introducing the interviewer’s own bias. There is also the risk of an inference gap, where context is misinterpreted or invented by the interviewer, since the stakeholders are not producing the rich picture themselves.
2.1.2 Root Definitions Wilson describes a Root Definition (RD) as “a way of capturing the essence (root) of the purpose to be served” (Wilson, 2001). A root definition should detail a transformation process, i.e. an input being transformed into an output. In the complex systems that SSM was designed to tackle, there may be vast numbers of these processes, from the high-level to the domain-specific, analytical models (Checkland, 1981). Each of these may then serve a different purpose depending on the viewpoint of the stakeholder 2
who is accessing the system. By defining the individual transformations taking place, the purpose of each process can be defined from the viewpoint of each stakeholder, leading to accurate requirement definition and system structure.
model remains conceptual. I.e., rather than specifying how or why Person A needs to make money for Person B, the CM would be modelled as a “system to make money”.
Transformation
2. Express the situation
Worldview
7. Take action
1. Find out about the situation
Mandatory 6. Define Changes - Desirable? - Feasible?
5. Compare
Recommended CATWOE
Actor
Owner
Real World
3. Define Definitions relevant to the situation
4. Develop Conceptual Models
Systems Thinking about the Real World Environmental Constraints
Customer
Figure 1. Checkland SSM. Figure 2. CATWOE Elements.
The application of the CATWOE mnemonic (Figure 2) serves to define a transformation process from the view of a particular stakeholder. The mandatory elements of the CATWOE are the transformation, defined by a verb, and the worldview, which details what must be believed for the RD to make sense. Individuals are defined as the customer (beneficiary of the transformation), actor (participant in the transformation) and owner (overall decision-maker with performance concerns) elements. By specifying the role an individual plays using the CATWOE structure, their role in the transformation can be defined uniformly. Environmental Constraints are taken as factors significant to the transformation process, which are external to the system itself.
2.1.3 Conceptual Models The purpose of the Conceptual Model (CM) is to model the transformation outlined in the RD as a series of activities, including the logical relationships between them, as well as a control sub-system. The purpose of the control sub-system is to define activities which monitor the performance of the activities and act on this to ensure the core activities serve their purpose. The CM expands on the RD transformation by exploring how to acquire the input, how to reach the output, and how to make the output available for the transformation detailed by the RD (Wilson, 2001). The monitor-and-control system is then applied. These questions are to be answered logically (not based on any pre-existing systems and solutions) to ensure the
The resulting CM should be defensible against the Formal Systems Model (FSM). This ensures that the resulting model describes a “system that is capable of purposeful activity without failure” (Peters et al., 2023). The application of the FSM is a Verification process (International Organization for Standardization et al., 2023), rather than an Architecture Definition process, falling outside the scope of this framework.
2.2 SysML v2 One of the mandatory requirements of SysML v2 was alignment with ISO 42010 (Object Management Group, 2017). This means the elements and relationships in the SysML v2 specification (Object Management Group, 2025), including stakeholders, concerns and viewpoints, are already positioned to accurately capture the intended meaning of the SSM outputs. To support this, several semantic relationships have been introduced, including: • Definition and Usage The Definition and Usage relationship allows for subsetting(:>), allowing a usage to be declared as one of the usages of another element, as well as redefinition (:»), where the inherited feature is replaced by a context-specific usage. • Metadata This replaces the SysML v1 stereotype. Data can now be tagged as inherent properties of an element rather than an annotation. • View Specification 3
The SysML view can now specify filter conditions to query specific parts of the model. This can then be visualised using a specified rendering usage. • Requirements as Constraints The SysML v2 requirement is a specialised constraint, which allows for the integration of textual description and logic, creating an executable natural language requirement. As features of SysML v2 are applied during the framework section, context will be added to aid comprehension for newcomers to the language.
3. Methodology The proposed framework seeks to specify a methodology for the uniform modelling of systems using SysML v2, defined first using SSM. This is accomplished in 2 stages: SSM modelling (utilising stakeholder interviews) and the application of a reference architecture for mapping SSM elements to SysML v2 elements. Modelling was completed using CATIA Magic System of Systems Architect, version 2026x.
Process Interview Data
Draft Rich Picture
Validate Draft
Inspect Draft
Inspect Draft
Approve Draft
Stakeholder Tasks
Reject Draft
Formalise Rich Picture
3.1 Rich Picture When engaging stakeholders to create a rich picture, it is recommended that 1-1 interviews are conducted, with the interviewer then producing a rich picture based on the results. While previously noted that this runs the risk of misinterpretation, there are existing models that can aid the formation of a question set to minimise this risk, ensuring relevant information is acquired. Of these models, this framework recommends the use of POPIT (People, Organisation, Processes, Information, Technology) (Paul et al., 2020) when forming a question set. Unlike a more traditional People-Process-Tools model (Leavitt, 1965), this ensures that data and artefacts, defined by POPIT as “information”, are considered separately from the technology used to access it. This distinction is crucial, as it enables the CATWOE Transformation, including inputs and outputs, to be captured accurately. The rich picture is then created using the interview dataset. The use of targeted questions addresses the risk of lost context during the interviews, but there remains the risk of misinterpretation. It is therefore recommended that the development of the rich picture be an iterative, collaborative process involving the individual stakeholders (Figure 3).
Figure 3. Collaborative Process with Stakeholder Involvement for Rich Picture Development.
Creating an initial, individual rich picture for each stakeholder and using follow-up sessions to validate the captured context will improve the accuracy of subsequent modelling and minimise potential rework.
3.2 Root Definitions To ensure the framework for modelling CATWOE elements using SysML v2 is accurate and effective, each CATWOE concept is mapped onto a (or a set of) SysML v2 element. This mapping was based on how the original intent of CATWOE can be represented most accurately using the enhanced semantic discipline of SysML v2, as depicted in the ontological interpretation of a subset of modelling concepts extracted from the SysML v2 metamodel, captured in Figure 4. To take advantage of the alignment with ISO 42010, the relationships contained within the
4
Stakeholder Context
Architecture Viewpoints
benefits
use case
was a boundary object which lacked internal funcOntology Case Study traceability from the tional behaviour, which limited Missing steps: - Subject. Need to decide on context to the structure and behaviour of the system. how a part is selected from C CATWOE. SysML v2 addresses this problem by classifying actors - Activity. How to decompose ofofpart definitions, allowing for local usages A useas caseusages (T) into a series action/transition/states. to be defined by global definitions. As this frame- Requirement. Outside T scope? work will be modelling real individuals, it is useful - Concern. Mention how Concern comes from W, may to include the new individual feature. By specifying W show how a new W may expand on a previousas an individual definition, then creating a a person viewpoint rather than make a (occurrence) of Othat definition, SysML v2 alnewusage one? - View conditions. How to get lows for the usage to be directly associated with systhese based on Rationale, E Concern. tem structure and behaviour (Figure 5). If this usage is specified within a use case, for example, this usage will only exist within this use case, limiting traceability. To maximise extensibility, the individual should C The local actor usbe specified outside the use case. age within the use case should Ac Athen subset (:>) this a high-level usage. ThisCmodelling om dem pattern allows for all usages of the individualm to Tbeictraced back to the erc Ve occurrence.
Architectural Descriptions
contains
action
triggers
transition
Conceptu Providing Acc
<<actor>>
Tool User : Actor
Actor
concerns
requirement
satifies
subject
performs
usage of
constrains
exhibits
state
exposes
view
constraint
part
targets/switches
specifies
rendering usage
<<actor>>
<<part>> Process Owner
<<use case>>
<<use case>> Giving Access to Tool
<<viewpoint>> Rationale
<<viewpoint>> Process Owner doc "Provide appropriate access to relevant Tool Users".
<<stakeholder>>
assumes
conforms
<<constraint>>
manifests
concern
frames
filter conditions
viewpoint
Stakeholder
rationale
documented by
<<part>> IT Department
Process Owner : Stakeholder
<<constraint>> Access Criteria
<<stakeholder>>
A System owned by O to do W by A by means of T given the constraints of E in order to achieve X for C
<<actor>>
New Hire Manager, IT Give Appropriate Access To New Hire New Hires need Appropriate Access to Tool, can be achieved by contacting IT and requesting change Manager Licenses, Job Role
Figure 4. Derivation of key SysML v2 concepts used in the framework. A System owned by Manager to provide appropriate access to a tool, by Manager and IT, by means of contacting IT to change permissions given the constraints of Licenses and Job Role to achieve appropriate access for New HIre
A System owned by a Manager to provide appropriate access to a tool, by Manager and IT, by means of contacting IT to change permissions given the constraints of Licenses and Job Role to achieve appropriate access for New HIre
Input - Job Role Access Level, Tool Access Register Transformation - Add Appropriate Access to Register Output - Register contains Appropriate Access for Job Role
<<use case>>
What has to be done to acquire the input? - Find appropriate access level What has to be done to reach the output? - Request IT to add access level to Register - Add to register What has to be done to make output available? - Notify new hire
Monitor Job Role Permissions
Job Role Tool Requirements
Manager Identifies Specific Job Role Permissions
IT Changes Permissions
Request Permissions Change from IT
IT Checks License Constraints
Maintain Appropriate Access for Job Role
Define the state machine Define the triggers, guards and actions for this Define the part which exhibits the state machine Define the part which performs the actions within the state machine Define requirements that the part states satisfy Link this part as a subject to an actor via a use case
A summary of the mapping of SysML v2 and CATWOE elements is provided in Table 1. CATWOE Element
SysML v2 Element
Customer
Individual as Stakeholder.
Actor
Individual as Actor.
Transformation
Use Case.
Worldview
Viewpoint (with Rationale).
Owner
Individual as Stakeholder.
Environmental Constraints
Requirements with Constraint.
rs De ion «individual occurrence def» ve for lop Te Person O me ac E n hing «individual occurrence» «individual occurrence» t i ss O Person A : Person Person B : Person tric nly tly Pr «concern» oh Concern i
W al
Manager Accesses Job Role Tool Requirements
SysML v2 metamodel has been laid out using the familiar concepts of a stakeholder context domain, architecture models, and the viewpoints which define them. This serves to summarise how different SysML v2 elements relate semantically, as well as defining the overall role they play in the architecture description. CATWOE and SysML v2 share common terms, such as actor. For clarity, CATWOE elements shall henceforth be capitalised.
Table 1. Summary of the SSM - SysML v2 Element mapping.
3.2.1 Actors The CATWOE Actors are the individuals who are performing the Transformation. In SysML v1, the actor
C.A. C.A.
License Information
<<viewpoint>> Rationale
<<stakeholder>>
<<constraint>>
Maintain Appropriate Number of Licenses
Monitor Required Number of Licenses
stakeholders
Concern Stakeholder :> Person A «use case» Use Case actors Ac a Co de mm mi erc c«use V case» ial UseerCase Specialised sio :> Use Case Dactors ev n fo Use Case Actor :> Person Be:>> lopUser Case T Actor me eac nt hing is str On and Figure 5. Modelling of an individual both as a stakeholder ict ly an actor. ly Pr oh ibi 3.2.2 Environmental Constraints t
Use Case Actor :> Person A
ed
In SysML v1, an external constraint could be modelled in one of two ways: as a requirement, which was text-based, or as a constraint block, which contained logic and equations. This meant a trade-off between legibility and functionality. The CATWOE Environ5
mental Constraint is perhaps the element which benefits the most from the switch to SysML v2. Requirements are now defined as specialised constraints, containing both the description of the requirement and at least one constraint. SysML v2 constraints can be specified in 3 ways: require, assume and assert. Require constraints serve to formalise the “shall” statement in the requirement. These are generally more suited to system requirements. The assume constraint specifies a list of conditions which must be satisfied before the require constraints apply, useful for modelling assumptions. The assert constraint specifies a condition that must be satisfied at all times. The Environmental Constraints should be modelled as requirements, which contain textual information about the constraint. The constraint can then be formalised using mathematics, with the exact application of the constraint decided on a case-by-case basis. By modelling this constraint at the start of the modelling process, it ensures that it can be traced to system elements, and the constraint can be adhered to.
3.2.3 Transformation and Customer The CATWOE Transformation is defined “either as an input-output conversion or the process itself” (Wilson, 2001). This distinction is important as, following the strict input-output definition, it would suggest the modelling of Transformation as an action. The SysML v2 action is performed by a part, and is defined by its inputs and outputs, which are generally parts or items. The action imposes an effect on its inputs and their parameters to define its outputs. This alone, however, lacks the high-level abstraction captured by the CATWOE Root Definition. The SysML v2 use case can be used to address the above issue. Specifically, a use case can be used to represent the high-level intent captured by the Transformation, while the actions embedded within the use case can be used to model the actual steps taken to achieve it. These actions are performed by the actors that are associated with the use case via the relationship shown in Figure 5. The subject of a use case will be the subject of the Transformation, which generally will be a part usage. The use case will also reference a requirement. As per CATWOE, the beneficiary of the Transformation is the Customer. This will be represented using the SysML v2 stakeholder. A stakeholder has a con-
cern, which is framed by the requirement satisfied by the use case, ensuring complete traceability. The stakeholder embedded in the concern can subset the individual occurrence as in Figure 5. This allows an individual to act as both a stakeholder and an actor while maintaining traceability to a single source.
3.2.4 Worldview and Owner In SysML v2, a viewpoint is defined as framing a concern which, according to ISO 42010 (International Organization for Standardization et al., 2022), is a “matter of interest to one or more stakeholders”. Unlike a SysML v2 Actor, which directly participates in the satisfaction of a requirement, a SysML v2 Stakeholder has concerns related to a requirement, to align more closely with ISO 42010. Therefore, the CATWOE Owner can be modelled as a SysML v2 stakeholder, as whilst they have concerns related to the Transformation, they do not (generally) directly perform it as an actor. Maintaining the pattern detailed in Figure 5 can allow an individual to act as both Owner and Actor, but the role of Owner itself is specified using a stakeholder element. The CATWOE Worldview is a “statement of belief” (Wilson, 2001) stating, from the perspective of the Owner, what the Transformation will achieve and how it will achieve it. As this comes from the point of view of the Owner, this is captured by a viewpoint, but this alone would not fully capture the intent behind the subjective view of the Owner. For example, a viewpoint may state what concern it is addressing, but it lacks the explanation of how and why this viewpoint was chosen. SysML v2 has introduced rationale as a native element in KerML, as opposed to the somewhat ad-hoc implementation in SysML v1. This allows for textual descriptions to be defined as an inherent property of an element. By including the Worldview as a rationale attached to the viewpoint, the intent of the Owner can be captured, ensuring clear traceability between the implementation and the original intent.
3.3 Conceptual Model Mapping The initial mapping detailed in Table 1 can provide a starting point to begin further system modelling with SysML v2. However, further system structure and behaviour can be modelled using the outputs from the SSM Conceptual Models. This includes the detailed decomposition of the use case, definition of require6
ments and definition of views. The theory behind the CM is simple (2.1.3 Conceptual Models). The challenge is to define a method for capturing it completely using SysML v2. It is therefore necessary to elaborate on the key capabilities of the SysML v2 Use Case.
For more complex systems, it can be more sensible to define structural behaviour separately. A powerful example of this is the SysML v2 state. Figure 6 shows how the state feature, formerly known as the state machine, can be defined within a part to specify its behaviour. Three states are exhibited by the kettle, with transitions defined using guards and by the acceptance of a send action within the use case, both following the standard trigger[guard]/action format. The use case specifies which parts of the system are interacted with, while the behaviour of those parts is specified separately. subject
targetTemp : CelsiusTemperatureValue := 100
objective
require Boiling Water «attribute» targetTemp : CelsiusTemperatureValue
«performer» Human :> Person A
«performer» Kettle :> Person A Kettle
perform actions
perform actions
Water «part» Person A Kettle
waterIn : Water
coldWater : Water «in ref» coldWater :> tap.tapWater
«exhibit state» Kettle Power States
['Power Supply' == true]
«state» standby
waterOut : Water
«action» turnOn
«assign» Kettle.Power Supply := true
«action» pressButton
«out ref» boiledWater :> kettleWater
ited
«assign» Kettle.Button.isOn := true
«item» kettleWater : Water «action» boilWater
BoilSignal
[Button.isOn == true]
«send» Water new BoilSignal() to Kettle
ited
«part» Button attributes
«action» turnOff
isOn : Boolean = false
doc
Water shall be heated to 100 C.
«assign»
subject
Kettle.Power Supply := false
water :> Person A Kettle.kettleWater stakeholders
Stakeholder :> Person A
require constraints
Temperature Goal {water.waterTemp == 100} waterIn : Water
frames
Water Temperature waterOut : Water «part» cup
boiledWater : Water
«action» fillCup
Water
Water
ited
subject
water :> Person A Kettle.kettleWater
«concern» Water Temperature
ited ly hib On Pro ing tly ach stric is Te for ent ion pm ers elo ic V Dev em rcial ad Ac mme Co
«requirement» Boiling Water
ited
ly hib On Pro ing ictly ach str Te is for ent ion pm ers velo ic V De em rcial ad Ac mme Co
['Power Supply' == false]
«state» on
«attribute» Power Supply : Boolean
ly hib On Pro ing ictly ach str Te is for ent ion pm ers velo ic V De em rcial ad Ac mme Co
ly hib On Pro ing tly ach stric is Te for ent ion pm ers elo ic V Dev em rcial ad Ac mme Co ['Power Supply' == false]
Water
«action» fillKettle
ited
«entry»
Water
Two kinds of system behaviour are demonstrated within this use case. Actions can have an effect on the subject as well as the parts it comprises. The ac-
actors
Human :> Person A Kettle :> Person A Kettle
attributes
3.3.1 Use Case Modelling
The key features are detailed in Figure 6. The simple example of using a kettle to boil water is used. An individual has a concern, which is framed by a requirement. The requirement includes both a description and a mathematical constraint. The subject of the concern and the use case should be the same to maintain consistency. The individual subsets the actor usage in the use case, performing the actions which represent their interaction with the system, with the kettle itself performing the heating action. The use case references a requirement in its objective, providing formal traceability from stakeholder concerns to system behaviour.
water :> Person A Kettle.kettleWater
«part» tap
«state» off
The SysML v2 part is a kind of item which can perform an action (Object Management Group, 2025). The item element itself can be used to represent the input and output of actions and parts and can have attributes of its own. This naturally aligns with the input and output of the Transformation, so it is recommended that, when specifying the behaviour of a system in a use case, one uses the following structure.
ly hib On Pro ing ictly ach str Te is for ent ion pm ers velo ic V De em rcial ad Ac mme Co «use case» Boil Water
«item def» BoilSignal
ly hib On Pro ing tly ach stric is Te for ent ion pm ers elo ic V Dev em rcial ad Ac mme Co
The use case will specify a subject; generally, this is a part. This framework will specify the subject as the part which is being transformed. The exact change in the part can be specified in two ways: using the input and output items of an action to show the change of parameters, or specifying states which the part can exhibit, and modelling the transition between them. The choice of method will be dependent on the Transformation itself, so both methods will be demonstrated in this framework. When an action is performed in a use case, an out item can be specified. If this item is modelling a signal, it is more useful to model the system separately, using the use case to model the actor’s interaction with the system via that signal. If the item itself is being transformed, then this can be modelled within the use case. Both methods are demonstrated in the following section.
tions turnOn, pressButton, and turnOff each contain an assign, which modifies attributes of the kettle to represent functional changes. Input and output reference usages define what enters and exits the system, aligning with the Transformation.
Figure 6. Use Case Modelling.
3.3.2 Conceptual Model Mapping Initial modelling details the input and output of the system, i.e., what is being transformed. The Transformation is then elaborated on, to define how the input is acquired, how to reach the output and how to make the output available. This is used to define a series of activities, their ordering and a monitor-andcontrol subsystem, which is itself made up of activities and relationships. The input and output will be the use case subject, either a part or an item. The activities can be defined as SysML v2 actions, which 7
generate effects on the subject, in the order specified in the CM.
3.3.3 Requirement Definition The individuals defined by the RD (Actor, Customer and Owner) can all be defined as a stakeholder, actor, or both. The actor is specified in the use case, and the stakeholder is specified in a high-level concern, i.e., safety. A requirement then frames that concern. In practice, however, the requirements will be defined separately. By framing the concern, it then falls under the umbrella of the concern, along with the other requirements which frame safety. As previously stated, the CATWOE Environmental Constraints will be modelled using the new requirement-constraint relationship. These will only inform the system from outside the boundary, however. To elicit a complete requirement set, a set of functional requirements should be elicited from the Transformation modelled, as well as the associated elements. Any industry-standard protocol can be followed to complete this and the ensuing nonfunctional requirements.
3.3.4 View Definition The primary application of the stakeholder-concern relationship in this framework is the ability to narrow the scope of the total system model to only the elements which are relevant to a particular concern. A SysML v2 view achieves this by exposing a portion of the model, filtering based on metadata, and then rendering in a manner of the modeller’s choosing, such as graphical, tabular, etc. This view then satisfies one or more viewpoints, which in turn frame one or more concerns held by one or more stakeholders. By specifying the subject of the transformation (use case) as the subject of the concern, traceability from the concern to the model elements is realised, allowing views to be specified according to a stakeholder’s root concern.
3.3.5 Metadata Definitions SysML v2 introduces metadata definitions, allowing new attribute sets to be defined and used across system elements. This metadata definition allows the specification of attributes of the metadata, such as a textual description. This implementation means that, as opposed to a stereotype or a tag in UML, elements can be queried and filtered within the tool.
Usage of metadata in elements will allow a more concrete reference with which filters can render views. These definitions can specify attributes, such as a textual description (Figure 7). When specifying a usage of that metadata in an element, that attribute can then be redefined. The definition of Rationale in the SysML v2 specification (Object Management Group, 2025) contains the string attribute “Text” which can be redefined. This is available in the “Modeling Metadata” library package, or can be modelled manually by following the specification. The metadata definition CATWOE contains an attribute “CATWOE Element”, which is typed by a list of enumerations. «metadata def» New Metadata
«part» Part
attributes
Description : String
metadata New Metadata
Description = "Information concerning New Metadata." Rationale
«enum def» Elements enums
Customer Actor Transformation Worldview Owner Environment
text = "Rationale details." «metadata def» CATWOE attributes
CATWOE Element[1..*] : Elements
Figure 7. Metadata Modelling.
4. Case Study System In the previous section, the technical foundation of the framework was detailed. In order to aid comprehension of the framework, a reference architecture has been populated using the outputs of a case study. This reference architecture and completed case study architecture can be found in the dedicated GitHub Repository (Harrison, 2025). Studying the textual notation and graphical views available in the repository is strongly advised to support understanding of the key concepts used in the framework. Descriptions of the foundational concepts are provided in the following sections. SysML v2 elements used for each stage are italicised for differentiation from normal concepts and also for emphasis. To produce the SSM outputs, a portion of a larger rich picture was taken and anonymised. The overall rich picture was created based on a one-to-one interview with an individual who is a manager in their organisation. The question set used was designed to account for all elements of the POPIT model and is available in the GitHub Repository (Harrison, 2025). 8
TOOL A - APPROVED USERS
I'm the New Hire, for Job A!
PERSON A
PERSON C
PERSON B
PERSON D
PERSON E
IT TOOL A
Give License to New Hire for Job A!
NEW HIRE
6 CAPACITY 5 TAKEN 1 REMAINING
MANAGER - IT PROCEDURE FOR NEW HIRE, JOB A
• Transformation: Assign available license for correct tool to new hire • Worldview: Appropriate access should be given to new hires and license availability recorded • Owner: IT • Environmental Constraints: Job role specification, license availability
APPROPRIATE ACCESS
IT
JOB A
TOOL A
JOB B
TOOL B
JOB C
TOOLC
4.1 Stakeholder Context
IT
4.1.1 Individuals
Figure 8. Case Study Rich Picture.
The segment of the rich picture used in this case study (Figure 8) captured a process which the individual, henceforth referred to as the manager, engages with in their workplace. When a new hire enters the business, they require access to certain tools as per their job responsibilities. The manager then sends a request to the IT department, henceforth referred to as IT, who will assign an available license for the tool that job requires to the new hire. This particular excerpt was chosen as it is a common occurrence in the workplace. Following the SSM process (3.2 Root Definitions), the following RD was created: A system owned by IT, to maintain appropriate access and license capacity, by IT and the manager, by means of assigning an available license for the correct tool to a new hire, given the constraints of their job role specification and the license availability, to resolve a work request for the manager. Given that the rich picture intends to capture the system from the worldview of the manager, it can be tempting to assume that the Owner of the process is the manager. However, the rich picture shows that the Transformation, the assignment of a license, is performed by IT, and the action of the manager functions as the trigger of this Transformation. Thus, the Owner of the process should be defined as IT. Given this RD, the following CATWOE Elements were identified, and then subsequently modelled using SysML v2 based on the mapping defined in 3.2: • Customer: Manager • Actors: IT, Manager
The three individuals were modelled as individual occurrences which were defined by the individual definition Employee. This feature typing relationship allows for the possible extension of traceability and inherited properties at a later stage of model maturity. The attribute “name” was modelled at the definition level and redefined at the usage level. The occurrences were tagged with the appropriate CATWOE role using metadata. The central concern here was taken as “Resources”, typed by the “OwnerConcern” definition. This may be replaced by an existing concern if the outputs of this framework are to be integrated into an existing model. IT’s role of Owner was then formalised by the local stakeholder usage subsetting the occurrence “it” (Figure 9). «individual occurrence» it : Employee
«individual occurrence» newHire : Employee
metadata
attributes
CATWOE
:>> name = "New Hire"
CATWOE Element = (Actor, Owner)
«individual occurrence» manager : Employee metadata CATWOE
CATWOE Element = (Customer, Actor)
attributes
attributes
:>> name = "IT"
:>> name = "Manager"
nly ed hing O tly Prohibit r Teac ic ion fo ent is str rs e V «concern def» «concern» elopm emic Acad ercial Dev resources : OwnerConcern OwnerConcern omm Cmetadata subject
«individual occurrence def» Employee attributes
name : String
CATWOE
license : License
CATWOE Element = Owner
stakeholders
:> it
:> it
Figure 9. Case Study Individual Modelling.
4.1.2 System Structure To further elaborate on the stakeholder context, it is useful to begin modelling high-level system elements at this point. From the viewpoint of the manager, the purpose of the system is to give the new hire access to a tool by submitting a request to IT, who will add them to the appropriate tool license according to their job role. This immediately provides the references for three system elements (role, tool and license), which could be modelled using parts, as shown in Figure 11. As 9
which it may or may not currently have. Therefore, a reference part typed by the part definition License is modelled, with the optionality captured by the [0..1] multiplicity. These reference parts were redefined at the usage level and associated with the relevant usage through binding.
these are part usages, to ensure model completeness and to enable reuse, a corresponding system element type for each of the usages is modelled using part definition (Figure 10).
Ac Co adem mm ic metadata It was also noted that when a License is available, CATWOE erc Ver CATWOE Element = Environment ial sion there will be a finite capacity. License therefore conDe ve for T tains a record of the total capacity and the current allop ea me chi «requirement def» «requirement def» n location, producing a derived attribute which models EC1 :> EnvironmentalConstraints EC2 :> EnvironmentalConstraints nt is s g On doc doc tricthely availability. This provides other model elements, New hires shall be given access to tool necessary to New hires shall be given access to a tool only when tly perform their Job Role. there is availability. Pro as the state exhibited by Tool, with a dynamic such h subject subject role : Role toollicense : License ted level ofibilicense availability for use in guard conditions. require constraints «requirement def» EnvironmentalConstraints
{toollicense.available > 0}
4.1.3 Environmental Constraints role : Role
<refinement>
toollicense : License
Ac Co adem mm ic V «part «part def» erdef» cia ersio Role License lD n ev for parts elo Tecapacity : Integer attributes ref assignedEmployee : Employee ac : Integer pm allocated ref requiredTool : Tool h en/available = capacity - allocated t is in:gInteger str Only «part def» ictl yP Tool roh parts ibit ref license[0..1] : License ed attributes
The RD defines two constraints: the allocated permissions for license access according to the job role and the availability of the associated license. These constraints were modelled as separate requirement definitions, typed by definition “EnvironmentalConstraints” to inherit the Environment metadata tag. Before modelling the actions, the constraints of the use case must first be specified, as well as the requirements the use case will satisfy. The first requirement definition, EC1, states that “New Hires shall be given access to tools necessary to perform their Job Role”, while the second requirement definition, EC2, refines the first requirement further, stating that “New hires shall be given access to a tool only when there is availability”.
toolName : String
=
«part» roleA : Role
attributes
parts
:>> toolName = "ToolA"
«requirement» ec1 : EC1
subject
ed
«ref part» ^assignedEmployee : Employee
role
ibi t
Ac Co ade mm mic erc Ve ial rsio De n f ve or T lop e me ach nt ing is str Only ict ly Pr oh =
As EC2 concerns the parameter which models license availability, a require constraint can be defined (Figure 10). Require was chosen as the constraint is the condition to be satisfied by the Transformation, rather than a background assumption.
doc
New hires in Role A shall be assigned the apropriate tools and license.
ref requiredToolA :>> requiredTool
«ref part» license :>> license
Ac Co ade mm mic erc Ve ial rsio De n ve for lop Te me ach nt ing is str Onl ict y ly Pr oh
«part» toolA : Tool
role
ibi t
em ic [license.available <= 0] «state» «state» erc Ver capacityUnavailable capacityAvailable ial sion De [license.available > 0] ve for T lop ea c me nt hing is s On tric ly tly Study Initial System Structure - Definition. Figure 10. Case Pro hib ite d
ed
«exhibit state» licenseState
«requirement» ec2 : EC2
«ref part» requiredToolA :>> requiredTool
4.2 Architecture Viewpoints 4.2.1 Worldview
doc
New hires in Role A shall be assigned a license to Tool A only when there is available capacity.
«satisfy» ec1
subject
toollicense
=
«part» licenseA : License =
toollicense
Figure 11. Case Study Initial System Structure - Usage.
Reference parts were modelled at the definition stage to explicitly state what type of elements should be referenced. For example, a Tool requires a License,
The stakeholder concern, “resources : OwnerConcern”, was framed using a viewpoint, “licenseManagement : ResourceAllocation”. This captures the Worldview using the Rationale metadata. The defining viewpoint definition was tagged with the “Worldview” metadata, allowing for this to be captured in the usage. A view, “License Allocation”, was then modelled, which satisfies viewpoint “licenseManagement : ResourceAllocation”. This view can expose specific sys10
developed using the process described previously (2.1.3 Conceptual Models). The central activity system details the activities which comprise the Transformation and were assigned to either the manager Ac a or IT by colour. These activities were modelled using Co de mm mi «use case def» cV e actions. Two monitor-and-control systems are also r CATWOE_Transformation cia ers l D ion included, which specify necessary control actions, as ev elo for T CATWOE Element = Transformation pm eacwell as required sources of information. These may en hin transformationSubject t is g inform str Onl the further elicitation of requirements and ict y ly formalised constraints, although this was not their Pr «use case def» o AssignLicense :> CATWOE_Transformation includedhibin ite this stage of the modelling process.
tem elements and filter them based on metadata and typing. This was not found to be sufficiently mature enough to define a generic view specification, so was left blank as an illustrative view. «view def» LicenseAllocation
metadata
CATWOE
subject
Ac Co ade subject mm mi licenseManagement erc c Ve newEmployeeRole : Role :>> transformationSubject ial rsio De n ve for lop Te me ach «viewpoint def» nt ing ResourceAllocation is str Onl metadata ict y CATWOE ly Pr CATWOE Element = Worldview oh Ac ibi a Co de ted mm mi c erc Ve «viewpoint» ial rsio licenseManagement : ResourceAllocation De n ve for metadata Rationale lo ea pm Taccess text = "Appropriate should be given to new hires and license availability recorded." c en hin frames t is g O resources str nl ict y ly Pr oh ibi Figure 12. Architecture ted Viewpoint Modelling. «view» licenseA_Allocation : LicenseAllocation satisfy requirements
4.2.2 Transformation The high-level Transformation was defined using a use case, with the local actor usages subsetting individuals “it” and “manager”. This use case was typed by use case definition “AssignLicense”, which specifies that the subject must be typed by the definition “Role”. “AssignLicense” is typed by the use case definition “CATWOE_Transformation” and tagged using the Transformation CATWOE label. At this stage, all six CATWOE elements have been modelled and tagged using metadata. To further decompose the Transformation and system structure, the CM can be referred to (Figure 13), which was
Figure 13. Case Study Conceptual Model.
d
According to the RD, it is known that IT will add the new hire to the appropriate license, but the specifics are not known. Therefore, the implementation process is left abstract during modelling, with greater focus on the information which will be required to enable each of the activities. If, during specific applications of this framework, a greater level of detail is required, it is recommended that this is developed in collaboration with the relevant stakeholder as per Figure 3. This will ensure that the resulting solution meets the specific needs of the stakeholder, eliminating the possibility of wasted effort and rework.
4.3 Architectural Descriptions 4.3.1 Use Case To model the usage of this use case, a subject must be selected. A part “transformationSystem” was created, which includes the use case usage and the “Role A” usage to be occupied by New Hire, “roleA_NewHire”, which fills the role of subject via subsetting. The overall part “transformationSystem” details the process by which the Transformation is performed, including the sources of information required by each action. By modelling a part which includes the use case as the Transformation, rather than the use case alone, the full Transformation process and all necessary elements can be captured, answering the three questions previously described (2.1.3). This top-level part can also be exposed to generate the view, although the level of specificity shown in Figure 14 currently cannot be achieved through the generic use of filter and expose alone. The use case details illustrative steps for completing the Transformation, with actions being performed by actors. The exact location of different attributes is also defined using binding to reference usages. The two branches of the decision result in different outputs, one with a message, the other with an assign ac11
Academic Version for Teaching Only Commercial Devel opment is strictly Pro hibited
criptions
Academic Version for Teaching Only Commercial Devel opment is strictly Pro hibited
«part» transformationSystem metadata CATWOE
CATWOE Element = Transformation «item def» AccessRequest
«use case» assignLicenseA : AssignLicense
parts
subject
ref requestedRole : Role
: Role :>> newEmployeeRole actors
«item def» UnavailableNotice
manager it objective
doc Allocation of a license for Tool A to New Hire.
Academic Versionrequire ec2 for Teaching Only Commercial Devel opment is strictly Pro hibited
«part» roleA_NewHire :> roleA
«ref part» employee :>> assignedEmployee
Academicit Version for Teaching Only Commperform actions ercial Development is stri ctly Prohibited
«performer» manager
«performer»
perform actions
«ref part» ^requiredToolA :>> requiredTool «ref part» ^license[0..1] : License
«ref part» targetRole :> roleA_NewHire
= newHireIn : Role
«action» reviewAndRequest request : AccessRequest incomingRequest : AccessRequest AccessRequest «action» evaluateAvailability AvailabilityDecision
Academic Version for Teaching Only Commercial Devel opment is strictly Pro hibited
[evaluateAvailability.incomingRequest.requestedRole...]
[evaluateAvailability.incomingRequest.requestedRole...] «action» provisionAccess
Academec2ic Version for Te Commercial Devel actions aching Only opme assign licenseOut.allocated := licenseIn.allocated +1 nt is strictly Prohibited notice : UnavailableNotice
«action» informUnavailable
notice : UnavailableNotice
satisfy requirements
licenseIn : License
licenseOut : License
UnavailableNotice «action» rejectionReception =
Academic Version for Teaching Only Commercial Devel opment is strictly Pro hibited
=
«ref part» targetLicense :> roleA_NewHire.requiredToolA.license
Academic Version for Teaching Only Commercial Devel opment is strictly Pro hibited
Figure 14. Case Study Transformation Use Case.
tion which alters an attribute. By explicitly linking the possible scenarios to model elements, the accuracy and comprehensibility of the model are increased. Academic Version for Teaching Only Commercial Devel opment is strictly Pro hibited
5. Conclusions
The application of the framework to a case study revealed the following findings. Firstly, the textual notation has greatly enhanced the ease of precise modelling, making the use of feature typing and redefinition a natural part of the modelling process. Beyond using the textual notation itself, the language also allows the modeller to verify traceability when modelling graphically. As the size of the textual notation grew, however, it became more important to rely on the graphical representation to keep a clearer image of the entire model. This may present a barrier to entry for less experienced modellers, although it is anticipated that developments in the use of Large Language Models (LLMs) will address this as the area of research matures. The use of a framework provides a structured mapping
of concepts, creating an ideal environment for an LLM to be leveraged. This could include automated generation of new model elements which adhere to the framework, natural language explanations of the modelled concepts, and facilitating the definition of complex views. The graphical representation was found to be flexible, allowing for the modeller to present the system in the manner of their choosing without interacting with the underlying logic. However, it is noted that this risks misrepresenting the system structure and behaviour. This demonstrates further the requirement for the formalisation of view definitions using SysML v2. By applying filtering conditions, the benefits of the graphical notation can be maintained whilst helping an individual modeller avoid misrepresenting an already-defined system. The use of the SSM process was decidedly useful in producing a formalised and reproducible set of initial system elements. Using a reference architecture to model this was also successful. By providing the outputs, as well as the template and SSM outputs, to a subject matter expert or external entity responsi12
ble for modelling, the likelihood of accurate models should be increased. There were two significant challenges that were left unaddressed, however: further modelling of system elements, and integration with existing system elements. The use of a standardised format and a template should assist with the integration with other systems using the framework, but the integration with systems modelled using another framework, or no framework, should be investigated. This study has established a framework for applying Soft Systems Methodology practices and formalising its outputs using SysML v2 in a uniform and reasoned manner. By mapping CATWOE elements to specific SysML v2 elements via the reference architecture and applying this to a case study, the risk of solving the wrong problem is addressed, as the context is no longer ambiguous. This allows accurate communication of that context and, therefore, more accurate MBSE models. Whilst it was noted that the balance between textual and graphical modelling may require some nuance and expertise, it ultimately made enforcing precision on the model a more inherent part of the process, which can be carried into subsequent modelling activities.
6. Future Directions This framework has set out a methodology for formalising stakeholder context within the current limitations of initial SysML v2 deployment. To further develop the capabilities of the framework, it is necessary to explore the filter conditions of the view element, as well as how to query the model. By exploring these capabilities, extended frameworks can be defined for specific modelling applications, ensuring the accuracy of the graphical notation. Validation against the Formal Systems Model (FSM) was not completed as part of this framework. However, it is recommended that the SSM protocol include an FSM comparison in future extensions of this framework. The resulting use case modelling process can then be compared to that of this framework to explore potential benefits of an expanded SSM protocol, potentially offering increased levels of resolution. Thirdly, it is recommended that a case study be conducted investigating the application of this framework by individuals of varying MBSE and SSM experience. The benefits previously outlined may differ in weight depending on the modelling skill of the user.
By doing so, the results can be compared and act as a verification and validation process for the framework. Lastly, the monitor-and-control loops in Figure 13 have not been modelled in detail, to avoid confusion for the reader. It is recommended that the framework be extended to include a separate procedure for this using a sophisticated monitor-and-control system. This will further explore the capabilities of SysML v2 whilst also providing a second model, which can be used to investigate the integration of two systems modelled using this framework.
Acknowledgments Gemini was used for initial checking of grammar and continuity of figures. Corrections were verified before being applied by the authors.
References Almeida, J. P. A., Pires, L. F., Guizzardi, G., & Wagner, G. (2025). An analysis of the semantic foundation of KerML and SysML v2. Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), 15238 LNCS. https : //doi.org/10.1007/978-3-031-75872-0_8 Amissah, M., Toba, A.-L., Handley, H. A. H., & Seck, M. (2018). Towards a framework for executable systems modeling: An executable systems modeling language (ESYSML). SpringSim. Bustard, D. W., He, Z., & Wilkie, F. G. (1999). Soft systems and use-case modelling: Mutually supportive or mutually exclusive? Proceedings of the Hawaii International Conference on System Sciences. https://doi.org/10.1109/hicss.1999. 772894 Checkland, P. (1981). Systems thinking, systems practice. John Wiley & Sons. Cloutier, R., Sauser, B., Bone, M., & Taylor, A. (2015). Transitioning systems thinking to modelbased systems engineering: Systemigrams to SysML models. IEEE Transactions on Systems, Man, and Cybernetics: Systems, 45(4). https : //doi.org/10.1109/TSMC.2014.2379657 Gisby, A., Ross, C., Francis-Smythe, J., & Anderson, K. (2023). The ‘rich pictures’ method: Its use and value, and the implications for HRD research and practice. Human Resource Develop13
ment Review, 22(2). https://doi.org/10.1177/ 15344843221148044 Harrison, M. (2025). Github repository (Version 1.0). https://github.com/maatt1199/SSM-SysMLv2-Reference-Architecture International Organization for Standardization, International Electrotechnical Commission, & Institute of Electrical and Electronics Engineers. (2022). Software, systems and enterprise — architecture description. ISO/IEC/IEEE. https://www.iso.org/standard/74393.html International Organization for Standardization, International Electrotechnical Commission, & Institute of Electrical and Electronics Engineers. (2023, March). ISO/IEC/IEEE international standard - systems and software engineering–system life cycle processes. https : / / doi . org / 10 . 1109 / IEEESTD . 2023 . 10123367 Kausch, H., Pfeiffer, M., Raco, D., Rumpe, B., & Schweiger, A. (2025). Model-driven development for functional correctness of avionics systems: A verification framework for SysML specifications. CEAS Aeronautical Journal, 16(1). https://doi.org/10.1007/s13272-02400762-6 Leavitt, H. J. (1965). Applied organizational change in industry: Structural, technological and humanistic approaches. In J. G. March (Ed.), Handbook of organisations (pp. 1144–1170). Rand McNally. Li, Z., Faheem, F., & Husung, S. (2024). Collaborative model-based systems engineering using dataspaces and SysML v2. Systems, 12(1). https://doi.org/10.3390/systems12010018 Litwin, K., Amundson, I., Verma, D., & McDermott, T. (2024). Transforming AADL models into SysML 2.0: Insights and recommendations. SAE Technical Papers. https : / / doi . org / 10 . 4271/2024-01-1947 Mitroff, I. I., & Featheringham, T. R. (1974). On systemic problem solving and the error of the third kind. Behavioral Science, 19(6). https:// doi.org/10.1002/bs.3830190605 Morkevicius, A., Aleksandraviciene, A., & Krisciuniene, G. (2021). From UAF to SysML: Transitioning from system of systems to systems architecture. INCOSE International Symposium, 31(1). https://doi.org/10.1002/j.2334- 5837. 2021.00856.x Mukotekwa, C., & Carson, E. (2007). Improving the discharge planning process: A systems study.
Journal of Research in Nursing, 12(6). https:// doi.org/10.1177/1744987107078897 Object Management Group. (2017). Object management group systems modeling language (SysML®) v2 request for proposal (RFP) (tech. rep.). Object Management Group. http : / / www.omg.org/cgi-bin/doc.cgi?ad/2017-12-2 Object Management Group. (2022). Unified architecture framework (UAF) domain metamodel (DMM) version 1.2 (tech. rep.). Object Management Group. https://www.omg.org/spec/ UAF/1.2 Object Management Group. (2025). About the OMG system modeling language specification version 2.0. https://www.omg.org/spec/SysML/ 2.0/ Paul, D., Cadle, J., Eva, M., Rollason, C., & Hunsley, J. (2020). Business analysis (4th ed.). BCS, The Chartered Institute for IT. Peters, G., Fortune, J., & White, D. (2023). The formal system model. Journal of Systems Thinking, 3(1). https : / / doi . org / 10 . 54120 / jost . 0000010 Salado, A., & Wach, P. (2019). Constructing true model-based requirements in SysML. Systems, 7(2). https : / / doi . org / 10 . 3390 / systems7020019 Vaicenavičius, J., Wiklund, T., Kavolis, D., Draukšas, S., Kalkauskas, A., & Vaicenavičius, R. (2025). SysIDE: SysML v2 textual editing and analysis system: Overview and applications. CEAS Space Journal. https : / / doi . org / 10 . 1007 / s12567-025-00595-x Wilson, B. (2001). Soft systems methodology: Conceptual model building and its contribution (1st ed.). John Wiley & Sons.
14