Most requirements elicitation methods do not explicitly provide a systematic way for deciding the boundary of the usage context that should be taken into account because it is essentially difficult to decide which context element should be included as the system requirements. If a developer explores the context boundary in an ad-hoc manner, the developer will be faced with the frame problem because there are unlimited context elements in the real world where the target system exists. There are many application domains that should take into account the frame problem: security, safety, network threats, and user interactions. To deal with this problem, this paper proposes a new type of requirements analysis method for exploring the context boundary using guide words, a set of hint words for finding a context element affecting the system behavior. The target of our method is embedded systems that can be abstracted as a sensor-and-actuator machine exchanging the physical value between a system and its context. In our method, only the value-context elements, a kind of value objects, are extracted as the associated context elements. By applying the guide words, we can explore only a sequence of context elements affecting the data value and avoid falling into the frame problem at the requirements analysis phase.
Many embedded systems not only affect their context through actuators but also are affected by their context through sensors. The term context refers to the real world such as the usage environment that affects the system behavior.
In most cases, context is only roughly analyzed in comparison to functional
or non-functional system requirements. As a result, unexpected behavior may
emerge in a system if a developer does not recognize any possible conflicting
combinations between the system and its context. It is also difficult to decide
the boundary of the context that should be taken into account: which context
element, an object existing outside of the system, should be included as the
targets of requirements analysis. If a developer explores the context boundary in an
ad-hoc manner, he or she will be faced with the frame problem [
To deal with the frame problem in embedded systems, we propose CAMEmb (Context Analysis Method for Embedded systems), a context-dependent requirements analysis method. A context model is constructed from the initial system requirements by using the UML Profile for Context Analysis. This context model clarifies the relation between a system and its context. In CAMEmb, only the value-context elements, a kind of value objects, are extracted as the associated context elements because many embedded systems are abstracted as a sensorand-actuator machine exchanging the physical value between a system and its context. Applying the Guide Words for Context Analysis, we can explore only a sequence of context elements directly or indirectly affecting the data value observed or controlled by the system sensors and actuators. Other context elements not affecting the system observation and control are not taken into account because these context elements do not affect the system behavior. We can deal with the frame problem because we only have to consider limited number of context elements as the context of the target system.
The remainder of this paper is structured as follows. In Section 2, problems
in the current requirements analysis methods are pointed out in terms of the
frame problem. In Section 3 and 4, CAMEmb is introduced to deal with the
frame problem. In Section 5, we discuss on the relation between CAMEmb and
the problem frame approach [
In this section, typical problems in the current requirements analysis methods are pointed out by describing the specification of an electric pot as an example. 2.1
An electric pot is an embedded system for boiling water. Here, for simplicity, only the following is considered: 1) the pot has three hardware components: a heater, a thermostat, and a water level sensor; 2) the pot controls the water temperature by turning on or off the heater; 3) the pot changes its mode from the heating mode to the retaining mode when the temperature becomes 100 Celsius; and 4) the pot observes the volume from the water level sensor that detects whether water is below or above a certain base level.
In case of the electric pot, the water temperature should be taken into account as an important context element. Here, as an example, let us consider the specification that controls the water temperature. In most cases, this specification is described by implicitly taking into account the specific context—for example, such the context that water is boiled under the normal air pressure. A developer describes the software logic corresponding to the specific context—in this case, the pot continues to turn on a heater switch until the water temperature becomes 100 Celsius. Below is the specification described in pseudo code. This function describes that a controller continues to turn on a heater while the value of the temperature obtained from a thermostat is below 100 Celsius. The Boil function behaves correctly under the normal circumstance. // Boil function while thermostat.GetTemperature() < 100.0 do heater.On();
Although this traditional approach is effective, there is room for improvements because it does not explicitly consider the context elements such as water and air pressure. The above Boil specification looks correct. However, faults may occur if the expected context is changed—for example, the circumstance of the low air pressure. Because the boiling point is below 100 Celsius under this circumstance, the software controller continues to heat water even if its temperature becomes the boiling point. As a result, water evaporates and finally its volume will be empty. The water level sensor observes the volume, and the pot stops heating. Although this behavior satisfies the above system specification, the pot may be useless for the people who use it up on high mountains where the air pressure is low. 2.2
The boundary of the context should be determined from stakeholders’ requirements. If we consider climbers as customers of the pot, we have to admit that we failed in eliciting requirements in the above example.
It is not easy to define the context boundary even if the target users of
the system are determined. A developer will be faced with the frame problem
because there are unlimited context elements in the real world. There are some
studies that take into account the real world as a modeling target. For example,
Greenspan, S. et al. claim the necessity of introducing real world knowledge
into requirement specifications [
The context model shown in Figure 1 is created as illustrated in Figure 2. Figure 2 shows only the image of context analysis procedures. Please refer to Figure 1 when a detailed analysis result is needed.
First, context elements ( Context ), which are directly observed or controlled by a sensor or an actuator, are extracted. We regard the environment value as a context element because CAMEmb focuses on embedded systems based on sensing and actuating. We call these context elements “value-context elements”. In case of an electric pot, water level and water temperature are extracted since water level is observed by the water level sensor and water temperature is controlled by the heater.
An element directly observed by a sensor may be an alternative context element in such a case that the sensor cannot observe the original value of the target context element. For example, the pot wants to observe not the water level but the water volume. Next, we explore the target context elements by using
T ransf er . In the step 2, all paths from sensors and actuators to the target context elements are completely extracted. The initial context boundary is determined in this stage. In case of an electric pot, water volume and water temperature are extracted as the initial context boundary.
The initial context boundary is an ideal boundary in which system’s sensing and controlling are not affected by other factors. However, there are many factors affecting observation and actuation in the real world. We have to extract these factors in order to develop reliable embedded systems.
In CAMEmb, impact factors that affect the states of these context elements
are extracted using guide words. Guide words, hints for deriving related elements,
are effective for software deviation analysis [
In addition to the HAZOP guide words, CAMEmb provides a set of guide words specific to the context analysis as shown in Table 1. These guide words help us to find an obstacle that affects the system observation and control in terms of the context-value. By using these guide words, we can extract context elements that affect the context elements existing within the initial boundary. If there is a context element having the influence on another context element, we link them by the Af f ect association.
In case of an electric pot, the boiling point can be extracted as an impact factor for the water temperature by applying the guide word “factor that determines the upper limit” since the temperature does not become higher than the boiling point. Step 3 in Figure 2 shows this stage of the context analysis. 4.1
We have to continue to extract impact factors as many as possible to develop reliable systems. In case of an electric pot, the air pressure can be extracted as an impact factor for the boiling point by applying the guide word “factor related to a specific value” since the boiling point of the water is 100 Celsius under the circumstance of 1.0 atm. At this point, we finish the context exploration because we can find no more impact factors affecting the air pressure.
We can extract two context elements water volume and air pressure as the final context boundary.
As shown here, the boundary of the context is explored by using UML Profile for Context Analysis and Guide Words for Context Analysis. We can explore only a sequence of context elements directly or indirectly affecting the data value observed or controlled by the system sensors and actuators. Other context elements not affecting the system observation and control are not extracted. There are many context elements such as person, table, and light in the environment of an electric pot. However, these context elements do not affect the data observed or controlled by the pot. So, we do not have to take into account these context elements. These context elements exist out of the boundary. 5 5.1
In CAMEmb, we select only the elements affecting the data value observed or controlled by a system. We think that the value-based context analysis is reasonable because most embedded systems observe the input data from the environment through sensors and affect the environment by emitting the physical outputs through actuators. The system behavior is determined by the data observed by the sensors and controlled by the actuators. We have only to take into account the context elements explicitly or implicitly affecting the data linked with the T ransf er or the Af f ect associations. The context analysis terminates when there are no more context elements affecting the data. In our approach, the affection is determined by using guide words. Of course, the method using guide words is not complete. But, the method helps a developer to find the context elements affecting the system behavior as many as possible. 5.2
Jackson, M. proposes the problem frames approach in which relations between a
machine (a system to be developed) and the real world are explicitly described.
The approach emphasises on the importance of analysing the real world and the
problems. The notion of context in CAMEmb corresponds to the real world in the
problem frame. Examples of formalising requirements with problem frames can
be found in [
Parnas, D. L. and Madey J. propose the four-variable model [
Although we may not be able to apply CAMEmb to all the application domains, there are many domains that can be modelled as monitor-controller (or sensor-actuator) systems. Security, safety, network threats, and user interactions are examples of such domains. In these domains, context can be analyzed using our approach. For example, trust in the security domains correspond to value in CAMEmb. By defining the guide words that affect the trusts, we can explore the trust boundary. 6
In this paper, we proposed CAMEmb, a context-dependent requirements analysis method. As demonstrated in this paper, we could provide a method for exploring the context boundary. The idea of value-context elements and guide words plays an important role. We think that the essential idea of CAMEmb can be applied to other kinds of context such as security and safety in embedded systems. As the next step, we plan to apply CAMEmb to such an application.