## 2 Preliminaries
### Structured Features  
A feature is defined as a \"Unit of functionality of a software system that satisfies a requirement, represents a design decision, and provides a potential configuration option\" [16]. It encompasses the functionality and performance of the software as perceived from the user's perspective, bridging the problem space with the solution space [17]. The function block feature is an early model of the structured features used in considering both hardware and requirements during design [18]. Structured features are built upon the function block feature by organizing hardware and software elements into patterns, making it easier for developers to understand and design them. Structured features are used in embedded software development to explicitly express the relationships between hardware components and software functions and between requirements and design [19]. Structured features act as intermediaries between the requirement and design domains, possessing a lower level of abstraction than requirements but a higher level of abstraction than design artifacts. Therefore, structured features are designed to contain both requirements and design elements. As shown in Figure 2, the structured feature list \(L\), which is a collection of structured features, comprises the structured features. The attributes of the structured feature model are designed to organically connect the requirements with the design. The structured  
Figure 1: Component-based development process. feature model, denoted as \(SF_{id}\), is defined as a 6-tuple; as shown in Figure 2, it consists of a requirement ID (RID), action (A), input data (ID), output data (OD), input event (IE), and output event (OE). An attribute represents the action that the structured feature intends to perform, whereas the flow of data and event attributes such as \(ID\), \(OD\), \(IE\), and \(OE\) can be represented as attributes of the structured feature. \[\mathsf{L}=\{\mathrm{SF}_{id}\mid id\in\mathbb{N}\},\]  
\[\mathrm{SF}_{id}=\text{(RID, A, ID, OD, IE, OE)}\]  
**(1) RID** is the identifier of a requirement. **(2) A** refers to the action that must be performed. **(3) ID** is the input data required to perform the action, consisting  
of a data name and hardware elements. **(4) OD** is the output data produced after performing the action,  
consisting of a data name and hardware elements. **(5) IE** is the event required for the action to be performed,  
consisting of an event name and hardware elements. **(6) OE** is the event that indicates the action has been completed,  
consisting of an event name and hardware elements. The SFCAD method formalizes the connection between the problem space and solution space through structured features [20]. As shown in Figure 3, the SFCAD process is divided into component identification, where the components comprising the CSA are identified; component interaction, which defines the interfaces between the identified components; and component specification, which specifies the components. The connections between structured features and design elements in each process were confirmed in [4]. In this study, we further analyze the mechanisms connecting these processes. Structured feature analysis is derived from the hardware system model and the functional requirements specification. The scope of the hardware system model encompasses those elements of hardware systems that are affected by embedded software. The format used to describe functional requirements may vary depending on the project or group. Below is an example of the hardware system model, the functional requirements specification, and the list of structured features produced from these sources. Figure 3: Structured feature-based component architecture design process. Figure 2: Attributes of structured feature model. Figure 4 presents an example of the materials used to generate a structured feature list and the resulting outputs.