The Engineering Framework

Before one starts with a formal specification and verification one has to clarify where in the general process of engineering specification and verification has to be located. From figure 2.1 one can derive the following informations:

Figure 2.1: Engineering Core Elements

1. Stakeholder, problem (P): As a starting point for every engineering process a stakeholder is presupposed , who has a problem in his mind and who wants an engineer to translate his problem into a working solution as a running technical system providing all the support the stakeholder wants. This will result in some project proposal.

2. Requirements Analysis: To find a solution the engineer has to reconstruct the problem of the stakeholder into a description of an adequate set of tasks realized by a minimal set of agents (here assumed as: human user (U), technical system (S), and environment (E)).
   1. Use Cases: The use case diagram is a method for describing the usages of the system. The association between the actors and the use case represent the communications that occurs between the actors and the subject to accomplish the functionality associated with the use case. The subject of the use case can be represented via a system boundary. The use cases that are enclosed in the system boundary represent functionality that is realized by some behaviors (cf. [263]:Chapt.14). A Use case starts with general tasks descriptions and can then be broken down to more specific behavior.

   2. Requirements: In SysML a requirement specifies a capability or condition that must (or should) be satisfied. A requirement may specify a function that a system must perform or a performance condition a system must achieve. SysML provides modeling constructs to represent text-based requirements and relate them to other modeling elements. The requirements diagram described there can depict the requirements in graphical, tabular, or tree structure format. A requirement can also appear on other diagrams to show its relationship to other modeling elements. The requirements modeling constructs are intended to provide a bridge between traditional requirements management tools and the other SysML models. Modelers can customize requirements taxonomies by defining additional subclasses of the Requirement stereotype. For example, a modeler may want to define requirements categories to represent operational, functional, interface, performance, physical, storage, activation/deactivation, design constraints, and other specialized requirements such as reliability and maintainability, or to represent a high level stakeholder need (cf. [263]:Chapt.15). Another description can be read in the V-Modell XT Vers. 1.3: The Specification of Requirements has to ensure that the reasons for executing a project are documented systematically based on unambiguous decisions. ...the process module Specification of Requirements supports the specification of unambiguous, complete, realistic, understandable, consistent, repeatable, prioritized and stable user requirements, which are suitable for an economic realization and acceptance of a system. The user requirements must be specified in detail in order to enable the developer or supplier of the system to design, offer and realize optimum technical solutions (cf. [278]:Chapt. 6.7).

      Figure 2.2: From Use Case to Requirements (See SysML Standard 2007, fig.16.4)

      

      Thus the requirements can be understood as an incrementally detailed specification of the general tasks presented in the use cases (cf. figure 2.2).

   3. Meaning: One has to be aware that these descriptions as such have no meaning; the intended meaning is associated with these descriptions by the communicating agents like the stakeholder and the engineer. Visual diagrams can to a high degree represent the meant object directly by their visual structure, they look 'somehow' alike their intended objects. But strictly speaking one has to look for the meaning of these descriptions outside of these descriptions. Informally one can talk about this intended meaning of the stakeholder as understood by the engineer as the analysis of a certain problem P. A problem can roughly be characterized by a set of tasks T, thus, that the problem P is solved when this set of tasks T is solved. A task t can be considered as a set of possible start states S0, possible sequences of actions (or operations) which change the start state in a way that one can reach after finitely many actions at least one state which is a solution state (cf. figure 2.3). These postulated agents and their required behavior constitute the intended domain of meaning of the requirements descriptions. Therefore one can this domain of meaning see like a model. For this we propose the term Requirements Domain Model, RDM.

   4. Virtual Agents: the internal structures of the involved agents are not at stake here. To indicate this 'virtuality' of the system functions of the agents it will be used the notation U$^{0}$, E$^{0}$, S$^{0}$ where the 'zero' indicates that these agents are only given without their system functions. An abstract model of a system function (cf. the functional analysis part) will be encoded by a 'one' like U$^{1}$, E$^{1}$, S$^{1}$ and a real system function (cf. the implementation part) given as a running system will be encoded by a 'two' like U$^{2}$, E$^{2}$, S$^{2}$.

   5. Interfaces: To be able to translate the required tasks into required action sequences one has to define the surface of the agents, how they appear to each other. These surfaces with changing properties are called interfaces (I). Thus we have the user interface (U$^{0}$I), the environment interfaces (E$^{0}$I), and the system interface (S$^{0}$I). One can for each interface I distinguish two subsets: I-input and I-output. I-input are those properties of an interface, which can be changed by an event external to the system, where the set I-output represents those properties of an interface, which change by internal processes of the agent itself. Having appropriate interface specifications this will allow the inclusion of sequence diagrams to depict the interaction of multiple actors obeying some timely and logical order.

   6. Property Language: For the description of needed properties one needs a special langugae $L_{prop}$ called Property Language.

      Figure 2.3: Engineering Requirements Meaning

      

3. Functional Analysis; System function: Based on the system interface S$^{0}$I the engineer has to construct a system function S1 as S1: S$^{0}$I-input $\longrightarrow$ S$^{0}$I-output. This means that the model S1 of a system function responds with some I-output property if a certain I-input property is caused by some external event.

4. Verification: One has to verify whether the model of the system function S1 corresponds to the interactions specified by the Requirements Domain Model (RDM).

5. Realization, Implementation: Based on a model S1 of a system function one can finally translate S1 into an implemented real system S2 which also realizes a mapping S2: S$^{0}$I-input $\longrightarrow$ S$^{0}$I-output.

6. Validation: Finally one has to evaluate the implemented system function S2 within a validation process against the interface descriptions of the requirements phase. Thus one has to provide the user interface U$^{0}$I and the environment interface E$^{0}$I to test whether the implemented system function S2 really reacts like in the mapping required.