A Hybrid Requirements Engineering Methodology for Artefact Production for Medical Device Software ^†

Abstract

Medical device software requirements are represented through heterogeneous artefacts capturing stakeholder, environmental, operational, and behavioural perspectives. However, trace links alone do not explain how information evolves between representations or distinguish preservation, rule-based derivation, engineering judgement, and unresolved information. This paper presents an artefact-oriented requirements engineering methodology that makes these transformations explicit and traceable. Each transformation records its source information, transformation rules, analyst-introduced information, target artefact, and traceability relationships. Target information is classified as preserved, derived, or analyst-introduced, while unsupported mappings are retained explicitly for review. The methodology connects User Stories, state models, Problem Frames (PFs), functional groups, and Box Structure Development Method (BSDM) behavioural representations. A bounded Automated External Defibrillator (AED) case study provides an end-to-end proof of concept using an atomic information ledger. Preservation Rate (PR), Enrichment Rate (ER), Traceability Coverage (TC), and Review Rate (RR) quantify complementary properties of the transformation process, subject to the documented atomic decomposition and provenance classification. The results demonstrate distinct preservative, semantic, and integrative transformation profiles while showing that complete recorded trace coverage does not imply semantic completeness or trace correctness. Unresolved information remains explicit rather than being completed through unsupported assumptions. The study demonstrates the measurability and inspectability of artefact transformations and provides a basis for future tool-supported transformation, while broader empirical validation remains necessary.

1. Introduction

Requirements engineering (RE) is critical in medical device software, where incomplete or incorrectly interpreted requirements can propagate into safety-critical failures [1,2,3]. Medical device development therefore requires stakeholder needs to be systematically refined into engineering artefacts supporting subsequent design and assurance activities, consistent with IEC 62304 and the risk-management perspective of ISO 14971 [4,5].

Requirements information does not remain in a single representation. Stakeholder needs may evolve through User Stories, Use Cases, state-based models, Problem Frames (PFs), and behavioural specifications. These artefacts capture complementary perspectives and levels of abstraction, making requirements development a process of information transformation rather than the production of independent documents.

Such transformations introduce a significant challenge. Source information may be preserved, derived, reorganised, or enriched through engineering judgement. When these changes remain implicit, provenance and assumptions become difficult to determine, potentially weakening traceability between stakeholder intent and downstream representations [6,7]. Moreover, a trace link records that elements are related but does not necessarily explain whether the target information was preserved, derived through a rule, introduced through analyst judgement, or remains unresolved. Existing techniques provide useful individual views: PFs structure the machine, problem domains, and their interactions [8,9], while the Box Structure Development Method (BSDM) and Sequence-Based Specification (SBS) represent externally observable stimulus–response behaviour [10,11,12]. Their complementary use does not itself characterise how information evolves between artefacts.

This paper addresses this gap from an artefact-transformation perspective. Rather than focusing on a specific mapping between modelling techniques, the approach considers the broader requirements artefact chain. Each transformation records source information, transformation rules, analyst-introduced information, the target artefact, traceability relationships, and unresolved mappings, making information evolution and engineering interpretation explicit.

Accordingly, the research question is as follows:

How can heterogeneous requirements engineering artefacts be systematically transformed while making information preservation, enrichment, traceability, analyst intervention, and unresolved mappings explicit during the progressive refinement of medical device software requirements?

The paper makes three principal contributions:

• An artefact-transformation model that distinguishes preserved, derived, analyst-introduced, and unresolved information while maintaining explicit source–target traceability;
• Operational artefact-production rules connecting stakeholder-oriented, state-based, problem-oriented, and behavioural representations, including typed trace relationships and explicit handling of unresolved mappings;
• A bounded AED proof of concept using an atomic information ledger and four measures of transformation properties—Preservation Rate (PR), Enrichment Rate (ER), Traceability Coverage (TC), and Review Rate (RR)—to demonstrate transformation measurability and inspectability.

The scope terminates at structured behavioural requirements artefacts. Formal model generation, model checking, certification evidence, and claims of requirements quality, medical-device safety, regulatory compliance, or engineering performance are outside the primary scope. The evaluation demonstrates measurability and inspectability rather than statistical generalisability or superiority over alternative RE approaches.

The remainder of the paper is organised as follows. Section 2 positions the approach against related work. Section 3 defines the transformation methodology. Section 4 presents the AED case and worked transformation chain. Section 5 evaluates the resulting transformations. Section 6 and Section 7 discuss the results, limitations, conclusions, and future work.

2. Background and Related Work

Requirements engineering produces heterogeneous artefacts representing stakeholder, environmental, operational, and behavioural perspectives at different abstraction levels. Refinement therefore requires maintaining information and provenance across representations. This section positions the approach with respect to traceability, model transformation, progressive refinement, and the modelling techniques used in the methodology.

2.1. Requirements Artefacts and Traceability

Requirements typically evolve from natural-language descriptions towards structured representations of system boundaries, interactions, states, and behaviour [13]. Here, an artefact is a structured representation produced or consumed during RE, including User Stories, state models, Problem Frames, functional groups, and behavioural tables.

Requirements traceability concerns the forward and backward relationships between requirements and development artefacts [6,7]. Trace links also relate source and target elements across heterogeneous models and model-driven development [14,15]. However, a trace link identifies a relationship without necessarily describing how source information changed or establishing its semantic correctness. This work therefore distinguishes traceability preservation, which retains recoverable source–target relationships, from information preservation, which concerns semantic content retained during transformation.

2.2. Model Transformation and Progressive Refinement

Model-Driven Engineering (MDE) provides systematic source-to-target transformations and associated traceability, particularly when representations have explicit metamodels and transformation rules [14,16]. Integration between RE and model-driven development nevertheless presents challenges in requirements modelling, traceability, and automation [17].

The transformations considered here operate across semantically heterogeneous requirements artefacts. User Stories, state descriptions, Problem Frames, and behavioural tables do not simply encode the same model in different syntax; their transformation may require derivation, environmental interpretation, or engineering judgement. The contribution is to make this information evolution explicit, including cases where source information cannot justify a target element.

2.3. Complementary Requirements Representations

The methodology combines representations with complementary semantics. User Stories capture stakeholder goals, state models represent operational behaviour, and Problem Frames (PFs) relate requirements to the machine, environmental domains, and shared phenomena [8,9]. The Box Structure Development Method (BSDM) and Sequence-Based Specification (SBS) provide behavioural representations based on observable stimulus–response relationships and state-dependent context [10,11,12].

PF–BSDM integration represents one transformation between environmental and behavioural representations. The present contribution instead characterises the broader artefact network, including stakeholder and state-based sources, functional decomposition, and transformation-level traceability. Each transformation distinguishes preserved, derived, analyst-introduced, and unresolved information, making information evolution across the requirements chain explicit and measurable.

2.4. Research Gap

The existing work provides foundations for traceability, model transformation, progressive refinement, and individual RE techniques. However, transformations between heterogeneous artefacts may preserve information, derive new relationships, require engineering interpretation, or encounter information that cannot yet be mapped. These properties are not captured by source–target trace links alone.

The proposed methodology addresses this gap by recording the source information, transformation rules, analyst-introduced information, target information, traceability relationships, and unresolved mappings. This provides the basis for the transformation model in Section 3 and its quantitative evaluation in Section 5.

3. A Hybrid Methodology for Traceable Artefact Transformation

The proposed methodology connects stakeholder-oriented, state-based, problem-oriented, and behavioural artefacts through explicit transformations. Each transformation records whether information is preserved, derived, introduced through engineering judgement, or remains unresolved, together with its traceability relationships.

3.1. Artefact Transformation Network

Figure 1 shows the principal artefacts and dependencies. User Stories (USs) structure stakeholder requirements, while state models represent operational behaviour. Problem Frames (PFs) combine stakeholder and state information to identify environmental domains and shared phenomena. In parallel, the state model is partitioned into Functional Groups (FGs), and BSDM Black Boxes (BBs) integrate PF environmental semantics with state-dependent FG behaviour. Use Cases (UCs) may additionally provide actor–system interactions when required.

Figure 1. Artefact transformation network. Solid arrows represent transformation/information flow; traceability is retained between contributing source and target elements.

The resulting structure is a network rather than a linear pipeline: state information contributes to both PF construction and functional decomposition, while BSDM construction combines information from both branches.

3.2. Artefact and Transformation Model

An artefact is represented as

$$A_i=⟨E_i,I_i,{\tau }_i⟩,$$

(1)

where $E_i$ contains its elements, $I_i$ their requirements information, and ${\tau }_i$ their traceability relationships. A transformation is defined as

$$T_i=⟨A_s,I_s,R_t,I_a,A_t,\tau ⟩,$$

(2)

where $A_s$ and $A_t$ are source and target artefacts, $I_s$ is consumed information, $R_t$ the transformation rules, $I_a$ analyst-introduced information, and $\tau$ source–target traceability. Information generated by $R_t$ is denoted $I_d\left(T\right)$. Multiple source artefacts may contribute to the same transformation.

To operationalise $R_t$, each rule is represented as

$$R_t=⟨Pre,Map,Out,Fail⟩,$$

(3)

where $Pre$ specifies required inputs, $Map$ the mapping condition, $Out$ the target information produced, and $Fail$ the condition requiring review.

3.3. Atomic Information Decomposition

Evaluation uses atomic information elements: semantically distinguishable propositions that can be independently transformed or traced. Coding follows four rules: (i) one element represents one independently traceable proposition; (ii) independent actions, conditions, or constraints are separated; (iii) elements are not decomposed below the granularity needed by the transformation; and (iv) ambiguous information remains identifiable rather than being resolved during coding.

For example, treating “prepare the shock only when the required conditions are satisfied so that therapy can be delivered safely” as one element is too coarse. It is decomposed as $u_1=$ shock preparation, $u_2=$ required-condition constraint, and $u_3=$ safe-therapy objective. Conversely, lexical decomposition would be too fine because individual words are not independently transformable requirements information. Atomic decomposition and provenance classification involve analyst judgement; different defensible semantic boundaries or classifications may therefore affect metric values. The coding rules make these decisions explicit but do not eliminate analyst variability, motivating future inter-analyst evaluation.

3.4. Operational Artefact-Production Rules

Table 1 instantiates the operational rule schema for the principal transformations.

Table 1. Operational schema for the principal artefact transformations.

Transformation	Precondition	Mapping Condition	Output	Failure/Review
Stakeholder → US	Stakeholder need or goal	Associate actor, capability, rationale, and identifier	Structured US	Missing actor, intent, or goal
US/UC/ST → PF	Requirement and relevant interaction/state evidence	Map interacting entities to domains and observable interactions to phenomena	Machine, domains, phenomena, requirement	Domain/phenomenon lacks supporting evidence
ST → FG	States and transitions	Select related behaviour by declared functional concern without creating transitions	Localised behaviour and classification	No justified functional assignment
PF/FG → BB	PF phenomena and FG behaviour	Associate observable stimuli with responses in the applicable behavioural context	Stimulus–response behaviour	No justified behavioural correspondence

A rule-supported target element is classified as derived; information requiring additional engineering interpretation is analyst-introduced; and information without a justified mapping remains unresolved.

3.5. Information Evolution and Traceability

Each target information element is assigned exactly one provenance category:

$$I\left(A_t\right)=I_p\left(T\right)\dot{\cup }{I}_d\left(T\right)\dot{\cup }{I}_a\left(T\right),$$

(4)

where $I_p$, $I_d$, and $I_a$ denote preserved, rule-derived, and analyst-introduced information, respectively. Source information without a justified target mapping is recorded separately as $I_r\left(T\right)$.

Traceability is represented as a typed relation

$$\tau \subseteq E_s\times E_t\times L,L=\{\mathrm{preserves},\mathrm{derived-from},\mathrm{motivated-by},\mathrm{introduced-because-of}\}.$$

(5)

Thus, trace links record not only that elements are related but also the nature of their provenance. Multiple sources may contribute to one target and vice versa. A consumed source element has the outcomes

$$e_s\to \left\{\begin{array}{cc}{e}_t,\hfill & \mathrm{preserved},\hfill \\ {\widehat{e}}_t,\hfill & \mathrm{used}\mathrm{in}\mathrm{derivation},\hfill \\ \mathrm{Review}\left(e_s\right),\hfill & \mathrm{no}\mathrm{justified}\mathrm{mapping}.\hfill \end{array}\right.$$

(6)

Typed traceability improves provenance interpretation but does not establish semantic correctness. Consequently, TC measures trace coverage, not precision, granularity, or correctness.

3.6. Unresolved-Item Management

An element in $I_r\left(T\right)$ remains an open engineering item and follows

$$\mathrm{Detected}\to \mathrm{Documented}\to \mathrm{Assessed}\to \mathrm{Resolved}\to \mathrm{Closed}.$$

(7)

Its record retains the source, reason for review, responsible analyst, status, and resolution. Safety-relevant ambiguity or missing information is linked to the applicable risk-management activity and escalated rather than resolved through unsupported assumptions, providing an interface with ISO 14971 [5]. This does not imply that every unresolved element constitutes a hazard. Until resolution, its unresolved status and provenance propagate to dependent transformations.

3.7. Evaluation Measures

Four measures characterise transformation properties:

$$PR\left(T\right)={\displaystyle \frac{\mid I_p\left(T\right)\mid }{\mid I_s\left(T\right)\mid }},ER\left(T\right)={\displaystyle \frac{\mid I_d\left(T\right)\mid +\mid I_a\left(T\right)\mid }{\mid I\left(A_t\right)\mid }},$$

(8)

$$TC\left(T\right)={\displaystyle \frac{\mid \{e_t\in E_t:\exists e_s,l(e_s,e_t,l)\in \tau \}\mid }{\mid E_t\mid }},RR\left(T\right)={\displaystyle \frac{\mid I_r\left(T\right)\mid }{\mid I_s\left(T\right)\mid }}.$$

(9)

$PR$ measures information preservation, $ER$ enrichment, $TC$ recorded provenance coverage, and $RR$ unresolved source information. They use different denominators and are not expected to sum to one. These measures characterise transformation properties, not requirements quality, medical-device safety, regulatory compliance, or engineering performance. Their values should be interpreted relative to the documented atomic decomposition and provenance classification, which involve analyst judgement.

3.8. Requirements for Future Tool Support

Future tool support could provide artefact metamodels, transformation-rule storage, an atomic information ledger for $I_p$, $I_d$, $I_a$, and $I_r$, typed trace and unresolved-item management, and automatic calculation of PR, ER, TC, and RR. No automated transformation tool is implemented or evaluated in this study, and analyst-dependent semantic decisions are not assumed to be fully automatable.

Section 4 instantiates the methodology through the AED case, and Section 5 evaluates the resulting transformation records.

4. Automated External Defibrillator Case Study

The methodology was applied to a generic semi-automated Automated External Defibrillator (AED) constructed from publicly available device information. The bounded case covers electrode verification, cardiac-rhythm acquisition and analysis, shock preparation and delivery, and post-treatment reassessment. It is intended to exercise the artefact-transformation methodology rather than to provide a normative specification of a commercial AED.

The case provides an end-to-end transformation record and an auditable information ledger through which preservation, derivation, analyst intervention, unresolved information, and traceability can be examined as properties of the documented transformations.

4.1. Source Requirements, Provenance, and State Model

The case was constructed using publicly available AED documentation [18,19], which provides supporting evidence for electrode connection, rhythm analysis, shock preparation, operator interaction, therapy delivery, and post-treatment reassessment. These sources support a realistic research case and are not treated as a complete or normative AED specification.

Five User Stories define the stakeholder-oriented requirements considered in the bounded case (Table 2).

Table 2. AED User Stories used in the bounded case study.

ID	Actor	User Story
US01	Operator	Verify electrode contact so that the cardiac signal can be acquired reliably.
US02	Operator	Analyse the patient’s cardiac rhythm to determine whether a shock is indicated.
US03	Operator	Prepare the shock only when the required conditions are satisfied so that therapy can be delivered safely.
US04	Operator	Indicate when a shock is ready so that the advised therapy can be initiated.
US05	Operator	Reassess the patient after therapy so that the treatment sequence can continue appropriately.

The state model derived for the bounded requirements set contains 13 states: Off, Self-Test, Awaiting Electrodes, Checking Contact, ECG Acquisition, Rhythm Analysis, No-Shock Decision, Charging, Shock Ready, Shock Delivery, Post-Shock, CPR Interval, and Fault. These are organised into five functional groups: Initialisation, Electrode Preparation, Rhythm Assessment, Shock Delivery, and CPR/Fault Management.

The state model is a research artefact constructed from the bounded requirements and supporting device information. Its provenance distinguishes requirements motivating operational elements from external evidence supporting their interpretation. User Stories are traced to contributing state elements but are not assumed to determine the complete state model independently, which is particularly relevant to US03.

4.2. Worked Transformation Chain

US03 provides the worked example because it contributes to both environmental and behavioural refinement. A source statement is decomposed when its components can follow different transformation outcomes, with each element representing one independently classifiable semantic item. Applying this rule to US03 identifies three information elements:

$$I\left(\mathrm{US}03\right)=\{u_1,u_2,u_3\},$$

(10)

where $u_1$ denotes shock preparation, $u_2$ the required-condition constraint, and $u_3$ the safe-therapy objective. These are separated because they can follow different transformation outcomes. As defined in Section 3.3, the decomposition is a documented analytical decision and is not assumed to be unique.

The complete artefact path is

$$\mathrm{US}03\to {\mathrm{ST}}_{Shock}\to \{{\mathrm{PF}}_{03},{\mathrm{FG}}_{Shock}\}\to {\mathrm{BB}}_{Shock}.$$

(11)

The shock-related subset of the state model contains five states,

$$S_{Shock}=\{\mathrm{RhythmAnalysis},\mathrm{Charging},\mathrm{ShockReady},\mathrm{ShockDelivery},\mathrm{PostShock}\},$$

(12)

connected by four transitions:

$$\begin{array}{cc}\hfill t_1& :\mathrm{RhythmAnalysis}\to \mathrm{Charging},\hfill \\ \hfill t_2& :\mathrm{Charging}\to \mathrm{ShockReady},\hfill \\ \hfill t_3& :\mathrm{ShockReady}\to \mathrm{ShockDelivery},\hfill \\ \hfill t_4& :\mathrm{ShockDelivery}\to \mathrm{PostShock}.\hfill \end{array}$$

(13)

These nine elements are operational refinements supported by the bounded requirements and external device evidence rather than by US03 alone. Their provenance records the contributing requirement and supporting source where applicable. Within US03→ST, they are classified as derived because they are not explicitly present in the source User Story.

4.3. Problem and Functional Refinement

PF analysis identifies five relevant domains: Operator, Patient, Electrode System, Rhythm Analysis Function, and Energy Delivery System; and six interface phenomena: electrode-contact status, cardiac signal, rhythm classification, charging status, shock command, and therapy-delivery status.

These domains and phenomena are represented individually in the information ledger and treated as rule-based derivation supported by the requirement, operational model, and source evidence. Domain-boundary placement and phenomenon classification require engineering judgement and are recorded separately as analyst-introduced information $I_a$.

In parallel,

$${\mathrm{ST}}_{Shock}\to {\mathrm{FG}}_{Shock}$$

(14)

preserves the five states and four transitions without introducing new operational behaviour. Their classification under the Shock Delivery functional concern requires interpretation and is therefore recorded as analyst-introduced information.

4.4. Transformation Record

Table 3 records the four transformations using Equation (2). $I_s$ denotes the atomic requirements information consumed and counted by a transformation. Supporting device documentation is retained as provenance for operational interpretation but is not counted in $I_s$. Information generated by $R_t$ belongs to $I_d$, while $I_a$ denotes information requiring engineering judgement beyond the explicit rule.

Table 3. Transformation record for the US03 artefact chain.

Transformation	${\mathbf{I}}_{\mathbf{s}}$	${\mathbf{R}}_{\mathbf{t}}$	${\mathbf{I}}_{\mathbf{a}}$	$\mathbf{\tau }$
US03 → STShock	$u_1,u_2,u_3$	Associate the requirement with justified operational states and transitions	None	Requirement/source–ST links
US03/ST → PF03	Requirement and relevant operational information	Identify domains, interfaces, and shared phenomena	Boundary and phenomenon-classification decisions	US03/ST–PF element links
ST → FGShock	5 states; 4 transitions	Partition behaviour according to functional concern	Functional classification	ST–FG element links
PF03/FGShock → BBShock	Relevant phenomena and shock-related state behaviour	Associate environmental stimuli with state-dependent responses	Behavioural organisation	PF/FG–BB element links

The record distinguishes rule-based transformation from engineering judgement. Operational refinement produces the state structure; PF construction derives environmental elements while requiring interpretive decisions; functional grouping preserves operational information while introducing functional classification; and BSDM construction integrates environmental and state-based information. These classifications document the transformation process rather than analyst-independent properties of the requirements.

4.5. BSDM Behavioural Artefact

Table 4 shows the resulting BSDM Black Box fragment. Each row defines a state-dependent stimulus–response relationship and retains traceability to its contributing state and environmental information.

Table 4. Representative AED BSDM Black Box behaviour for the shock-delivery chain.

State	Stimulus	Response	Next State
Rhythm Analysis	Shockable rhythm	Initiate charging	Charging
Charging	Charge complete	Indicate shock readiness	Shock Ready
Shock Ready	Shock command	Deliver therapy	Shock Delivery
Shock Delivery	Delivery complete	Initiate reassessment	Post-Shock

Unlike a conventional transition table, the BSDM Black Box characterises externally observable behaviour by associating environmental stimuli with responses in the applicable state context. PF analysis supplies environmental semantics, while the functional group supplies state-dependent behavioural context. The target therefore integrates both transformation branches rather than simply reproducing the state model.

For quantitative analysis, the four stimulus–response relationships are recorded as derived elements $b_1$–$b_4$. Contributing states, transitions, and phenomena retain their identities and trace links rather than being recounted as new information. Their organisation as state-dependent Black Box behaviour requires an additional engineering decision recorded as analyst-introduced information.

4.6. Atomic Information Ledger and Unresolved-Item Handling

Table 5 summarises the atomic elements used for the quantitative evaluation of transformation properties. The identifiers prevent categories such as “states” or “phenomena” from being counted as single information elements.

Table 5. Atomic information ledger for the US03 transformation chain.

IDs	Information Elements	Extent	Role
$u_1$–$u_3$	Shock-preparation goal, required-condition constraint, safe-therapy objective	3	Source requirement
$s_1$–$s_5$	Shock-related operational states	5	Derived state information
$t_1$–$t_4$	Shock-related transitions	4	Derived transition information
$d_1$–$d_5$	Operator, Patient, Electrode System, Rhythm Analysis Function, Energy Delivery System	5	Derived PF domains
$p_1$–$p_6$	Contact, cardiac signal, rhythm classification, charging status, shock command, therapy-delivery phenomena	6	Derived PF phenomena
$a_1$–$a_2$	Domain-boundary and phenomenon-classification decisions	2	Analyst-introduced
$a_3$	Shock Delivery functional classification	1	Analyst-introduced
$b_1$–$b_4$	State-dependent stimulus–response relationships	4	Derived behaviour
$a_4$	Black Box behavioural organisation	1	Analyst-introduced

Classification is transformation-relative: an element derived in one transformation may be preserved in another. For example, states derived during operational refinement are subsequently preserved by ST → FG. Classification also depends on the documented atomic decomposition and whether the transformation rule sufficiently determines the target element; alternative defensible analyst classifications may therefore affect the quantitative values.

One source element remains unresolved. The term safe in $u_3$ does not uniquely determine the conditions under which therapy may be delivered. Electrode contact, rhythm classification, device status, charging status, and operator interaction may contribute, but treating them as the complete meaning of safe would introduce an unsupported assumption. Therefore,

$$u_3\to \mathrm{Review}\left(u_3\right),u_3\in I_r\left(T\right).$$

(15)

The unresolved record retains its originating requirement, affected downstream artefacts, reason for non-resolution, and review responsibility. If additional requirements evidence cannot resolve the ambiguity and it may affect a hazardous situation, safety-related behaviour, or risk-control requirement, it is referred to the ISO 14971 risk-management process. Until justified evidence is obtained, its unresolved status propagates to dependent transformations rather than being replaced by an unsupported assumption.

Closure requires additional evidence establishing a justified mapping or a formally accepted and recorded engineering decision. The transformation record and trace relationships are then updated. Thus, $I_r$ represents an actionable review state and the basis of the Review Rate defined in Section 3.7.

The ledger therefore provides the counting basis for distinguishing preserved, derived, analyst-introduced, and unresolved information in the quantitative evaluation of Section 5.

5. Evaluation

The methodology was evaluated at two levels: artefact coverage across the bounded AED case and information-element analysis of the complete US03 transformation chain using the Preservation Rate (PR), Enrichment Rate (ER), Traceability Coverage (TC), and Review Rate (RR) defined in Section 3.7. These measures characterise properties of the documented transformations rather than requirements quality, medical-device safety, regulatory compliance, or engineering performance.

5.1. Artefact Coverage

The bounded case contains five User Stories and a derived behavioural model of 13 states organised into five functional groups. Together, the artefacts cover stakeholder-oriented, state-based, problem-oriented, and behavioural representations, as summarised in Table 6.

Table 6. Artefact coverage in the bounded AED case.

Artefact	Extent	Information Represented
User Stories	5	Stakeholder goals and treatment-related requirements
State Model	13 states	Operational states, events, and transitions
Functional Groups	5	Localised behavioural concerns
Problem Frames	Requirement-based	Domains, phenomena, and responsibilities
BSDM Black Boxes	Functional-group based	State-dependent stimulus–response behaviour

The case is intentionally compact rather than a complete AED specification and is used to exercise the principal artefact classes and transformations of the methodology.

5.2. Information-Element Coding

The quantitative analysis uses the atomic information ledger in Table 5. For each transformation, target elements are classified as preserved ($I_p$), derived ($I_d$), or analyst-introduced ($I_a$), while source information without a justified target mapping is recorded separately as unresolved ($I_r$). Classification is transformation-relative: an element derived in one transformation may be preserved by another.

Atomic decomposition and provenance classification involve analyst judgement. Different defensible granularities or classifications may therefore affect PR, ER, and RR. The coding rules constrain this variation but do not eliminate it; so, the values are interpreted relative to the documented ledger rather than as analyst-independent properties of the requirements.

Traceability is assessed independently. A target element is traceable when at least one explicit relationship to contributing source information is retained. TC measures the coverage of this recorded provenance, not the precision, granularity, or semantic correctness of the trace relationship.

5.3. Quantitative Results

Table 7 reports the atomic information counts for the worked US03 chain. Only information consumed by each transformation is included in $I_s$.

Table 7. Information-element analysis of the US03 transformation chain.

Transformation	$\mid {\mathbf{I}}_{\mathbf{s}}\mid$	$\mid {\mathbf{I}}_{\mathbf{p}}\mid$	$\mid {\mathbf{I}}_{\mathbf{d}}\mid$	$\mid {\mathbf{I}}_{\mathbf{a}}\mid$	$\mid {\mathbf{I}}_{\mathbf{r}}\mid$
US03 → STShock	3	0	9	0	1
US03/ST → PF03	12	1	11	2	1
ST → FGShock	9	9	0	1	0
PF03/FGShock → BBShock	13	9	4	1	0

The first transformation is predominantly derivational. Its nine states and transitions are operational refinements supported by the bounded requirements and device evidence rather than information explicitly contained in US03. The meaning of safe, represented by $u_3$, remains unresolved.

PF construction consumes the three US03 elements and nine state elements ($\mid I_s\mid =12$). One requirement element is preserved, five domains and six phenomena are derived, two classification decisions are analyst-introduced, and $u_3$ remains unresolved.

Functional grouping preserves all five states and four transitions ($\mid I_p\mid =9$) and introduces one functional-classification element without deriving new operational behaviour. The PF/FG→BB transformation consumes five states, four transitions, and four environmental phenomena: nine elements are preserved, four stimulus–response relationships are derived, and one Black Box organisation element is analyst-introduced.

Applying Equations (8) and (9) gives Table 8.

Table 8. Quantitative measures of transformation properties for the US03 chain.

Transformation	PR	ER	TC	RR
US03 → STShock	0.00	1.00	1.00	0.33
US03/ST → PF03	0.08	0.93	1.00	0.08
ST → FGShock	1.00	0.10	1.00	0.00
PF03/FGShock → BBShock	0.69	0.36	1.00	0.00

For example, the PF/FG→BB transformation gives

$$PR={\displaystyle \frac{9}{13}}=0.69,ER={\displaystyle \frac{4+1}{9+4+1}}=0.36.$$

(16)

The measures describe different transformation roles rather than a common optimisation objective. Low preservation is not inherently undesirable: operational refinement introduces structure absent from the stakeholder representation, whereas functional grouping reorganises existing behaviour. Similarly, $PF$ construction is predominantly enriching, while BSDM construction combines preservation ($PR=0.69$) with behavioural enrichment ($ER=0.36$). These profiles are not rankings of requirements quality, safety, regulatory compliance, or engineering performance.

5.4. Traceability and Transformation Integrity

All target elements in the worked chain retain at least one explicit relationship to contributing source information, giving $TC=1.00$ for all four transformations. This indicates complete recorded trace coverage within the evaluated chain, not trace correctness or quality. TC does not assess the precision, granularity, or semantic correctness of those relationships.

RR captures unresolved source information. The element $u_3$ expresses safe therapy delivery, but the source does not uniquely define the meaning of safe; it therefore remains in $I_r$ rather than being completed through an unsupported assumption. For the initial transformation,

$$RR={\displaystyle \frac{\mid I_r\mid }{\mid I_s\mid }}={\displaystyle \frac{1}{3}}=0.33.$$

(17)

When US03 and the relevant state information contribute to PF construction, the same unresolved element gives $RR=1/12=0.08$. Its continued traceability shows that the recorded provenance and semantic completeness are distinct: an element may be traceable, while its semantic mapping remains unresolved.

5.5. Interpretation and Evaluation Limits

The analysis exposes distinct transformation profiles. Operational refinement is predominantly derivational, functional grouping preservative, PF construction combines derivation with analyst-dependent interpretation, and BSDM construction integrates existing information while deriving behavioural relationships. The explicit $I_r$ category prevents unresolved information from being counted as successful transformation.

The results demonstrate that preservation, enrichment, recorded traceability, and unresolved information can be measured and inspected as properties of the documented transformations. Their values depend partly on analyst decisions concerning atomic decomposition and provenance classification; alternative defensible decisions may therefore produce different values. Inter-analyst agreement and reproducibility have not yet been evaluated. Accordingly, the measures are not analyst-independent properties of the requirements or direct measures of requirements quality, medical-device safety, regulatory compliance, or engineering performance.

Likewise, $TC=1.00$ indicates complete recorded provenance within the evaluated chain, not trace precision, granularity, semantic correctness, or completeness of the underlying requirements.

Finally, the evaluation covers one fully documented transformation chain in a bounded AED case. It demonstrates proof-of-concept measurability and inspectability rather than statistical generalisability, real-world performance, or superiority over alternative RE approaches. Future evaluation should use larger independently developed requirements sets, multiple analysts, effort measurement, comparison with alternative workflows, and assessment of trace quality and inter-analyst reproducibility.

6. Discussion

The AED case shows how heterogeneous requirements artefacts can be connected through explicit transformations. User Stories, state models, Problem Frames, functional groups, and BSDM representations provide complementary perspectives through progressive refinement rather than simple notation conversion.

The quantitative results expose distinct transformation profiles. ST→FG is predominantly preservative ($PR=1.00$, $ER=0.10$), whereas PF construction introduces environmental structure and semantics. The PF/FG→BB transformation combines both characteristics ($PR=0.69$, $ER=0.36$). These measures characterise properties of the documented transformations and should therefore be interpreted according to transformation purpose rather than as competing objectives or as direct measures of requirements quality, medical-device safety, regulatory compliance, or engineering performance.

Traceability is distinct from preservation and semantic correctness. Although all target elements retained recorded provenance ($TC=1.00$), $TC$ measures trace coverage, not link precision, granularity, or semantic correctness. Typed relationships such as preserves, derived-from, motivated-by, and introduced-because-of make provenance more explicit, while trace quality requires separate assessment [6,7]. Thus, complete recorded trace coverage should not be interpreted as evidence that the trace relationships or the underlying requirements are semantically correct or complete.

The unresolved meaning of safe in US03 further demonstrates that provenance does not imply semantic completeness. Unresolved information remains traceable and propagates to dependent artefacts until reviewed and resolved. Where it concerns hazardous behaviour or risk controls, it should also be linked to ISO 14971 risk-management activities [5]. This avoids unsupported interpretation while retaining the information requiring engineering attention.

The methodology provides a basis for future controlled tool support rather than demonstrating automated transformation. Structural operations such as functional grouping, trace propagation, transformation-record management, and metric calculation are candidates for tool support, whereas domain identification, phenomenon classification, provenance classification, and the interpretation of ambiguous requirements remain dependent on engineering judgement. Future tools could manage transformation records, atomic ledgers, metrics, typed traces, and unresolved items while keeping semantic decisions explicit and reviewable.

Analyst judgement also affects the quantitative results. Although the coding procedure and atomic ledger in Section 4.6 constrain and document these decisions, alternative defensible atomic decompositions or provenance classifications may produce different PR, ER, and RR values. Consequently, the reported values should be interpreted together with their underlying ledger and coding procedure. Inter-analyst agreement and reproducibility have not been evaluated in the present study, limiting the generalisability of the numerical results.

For medical device software, the approach supports requirements refinement and traceability consistent with IEC 62304 and the risk-oriented perspective of ISO 14971 [4,5]; however, this consistency should not be interpreted as evidence of regulatory compliance. The methodology and its metrics do not directly establish requirements quality, device safety, regulatory compliance, implementation correctness, or engineering performance.

The evaluation remains a proof of concept based on one fully documented transformation chain within a bounded AED case. Broader validation requires larger independently developed requirements sets, multiple analysts, comparative baselines, and assessment of effort, coding agreement, inter-analyst reproducibility, and trace quality.

Overall, the transformation network makes information evolution, provenance, unresolved information, and analyst intervention explicit and inspectable across heterogeneous requirements artefacts. The quantitative measures provide a means of characterising these transformation properties within the documented coding procedure rather than measures of the quality or correctness of the requirements themselves.

7. Conclusions and Future Work

This paper presented an artefact-oriented requirements engineering methodology that makes transformations between heterogeneous artefacts explicit and traceable by distinguishing preserved, derived, analyst-introduced, and unresolved information throughout refinement.

A bounded AED proof of concept demonstrated an end-to-end transformation chain using an atomic information ledger and quantified its transformation properties through PR, ER, TC, and RR. The results expose different transformation profiles and show that complete recorded trace coverage does not imply semantic completeness or trace correctness. Explicit treatment of unresolved information also prevents unsupported assumptions and supports their review across dependent artefacts. The reported measures characterise the properties of the documented transformations rather than requirements quality, medical-device safety, regulatory compliance, or engineering performance, and their values are conditioned by the documented atomic decomposition and provenance classification.

The contribution is a measurable and inspectable account of requirements information evolution that supports traceable artefact production and provides a basis for future tool support rather than demonstrating automated transformation. The evaluation demonstrates proof-of-concept measurability and inspectability rather than statistical generalisability or comparative superiority. Future work will examine larger independently developed medical-device requirements sets, multiple analysts, inter-analyst coding agreement and reproducibility, trace quality, transformation effort, and comparative baselines, together with tool support for transformation records, atomic ledgers, metric calculation, traceability, and unresolved-item management.