The SpesML Maturity Matrix
In this section we present the SpesML Maturity Matrix which is the representation of the model in matrix format. This representation allows for easy referencing and maturity comparison.
| Viewpoint | Focus Areas | Capability A | Capability B | Capability C | Capability D |
|---|---|---|---|---|---|
| Requirements Viewpoint | Requirements Elicitation (REE) | REE A: Requirements are modeled by a distinct requirement element per requirement. | REE B: Requirements are categorized into one of the categories: Capability, Functional, Quality, Constraint. Pre-req: REE A | ||
| Requirements Specification (RES) | RES A: Requirements are equipped with attributes containing meta-information including: name, category, status, rationale, and source. | RES B: Requirements text is formulated following certain sentence templates (e.g., EARS or Sophist MasterTemplate) ( C). | RES C: The requirements text is aligned with modeling elements that they are related to (e.g., naming of ports or internal states) ( C). | ||
| Requirements Refinement (REF) | REF A: If a low-level requirement is derived from a high-level requirement, they are related by a derived relation. Note: Both requirements must address the same system scope. | REF B: If a system requirement is broken down to several component requirements, the system requirement is related to the component requirements by a decompose relation | REF C: If a requirement satisfies a property that is required in another requirements, the requirements are related by a match relation. | ||
| Viewpoint | Focus Areas | Capability A | Capability B | Capability C | Capability D |
| Functional Viewpoint | System Function Modeling (SFM) | SFM A: System functions are modeled with a syntactic interface (inputs and outputs). | SFM B: System functions are related with a satisfy or require relationship to requirements they satisfy or assume. | SFM C: The behavior of the system functions is modeled by a state machine or decomposed in a white-box model. | SFM D: The model of the system functions can be simulated together with a description of the context. |
| White-box Modeling (WBM) | WBM A: The white-box functions that implement a system function are modeled with a syntactic interface (inputs and outputs). | WBM B: White-box functions are related with a satisfy or require relationship to requirements they satisfy or assume. | WBM C: The behavior of the white-box functions is modeled. | ||
| Functional conText Modelling (FTM) | FTM A: The system under development (i.e., the top-level system function) is modeled by a composition of all system functions. | FTM B: Functions of the operational context (e.g., external inputs) are modeled with a syntactic interface (inputs and outputs). Note: Functions do not need to be allocated to actors yet. | FTM C: For each function in the operational context, the behavior is modeled. | ||
| Mode Modeling (MOM) | MOM A: The operating modes of a system are modeled in terms of a state machine. | MOM B: The operating modes in the mode model are consistent with the mode channels between the systems functions. | |||
| Viewpoint | Focus Areas | Capability A | Capability B | Capability C | Capability D |
| Logical Viewpoint | Logical Component Modeling (LCM) | LCM A: For logical components, their interface is modeled with associated input and output signals. | LCM B: The behavior of the logical components is modeled. | LCM C: Logical components and requirements they satisfy are related by a satisfy or require relation. | |
| Logical Architecture Modeling (LAM) | LAM A: The logical components and their dependencies are modeled. | LAM B: Logical components are related to white-box functions that they implement by a realize relation. | |||
| Logical conText Modelling (LTM) | LTM A: The system under development (i.e., the top-level logical component) is modeled by a composition of all logical components. | LTM B: Actors of the operational context (e.g., external systems or users) are modeled with a syntactic interface (inputs and outputs). | LTM C: For each actor in the operational context, the behavior is modeled. | ||
| Logical Physical Modelling (LPM) | LPM A: Physical components and cyber components (SW-Subsystem) are identified and modeled as separate components in the logical structure. | LPM B: Interface behavior between the physical components and the SW-Subsystem is modeled on a high level of abstraction. | LPM C: Physical behaviour of the SUD and Context elements are modeled on a high level of abstraction. | LPM D: Aspects of the physical behaviour of the SuD are included when simulating the logical components. | |
| Viewpoint | Focus Areas | Capability A | Capability B | Capability C | Capability D |
| Technical Viewpoint | Technical Component Modeling (TCM) | TCM A: For technical components, their interface is modeled with associated input and output signals. | TCM B: Technical components and requirements they satisfy are related by a satisfy or require relation. | ||
| Technical Architecture Modeling (TAM) | TAM A: The technical components and their dependencies are modeled. | TAM B: Technical components are related to logical components that they implement by a realize relation. | |||
| Technical conText Modelling (TTM) | TTM A: The system under development (i.e., the top-level technical component) is modeled by a composition of all technical components. | TTM B: Actors of the operational context (e.g., external systems or users) are modeled with a syntactic interface (inputs and outputs). | |||
| Modeling of SW Execution Platform (HAM) | HAM A: Necessary HW elements of the execution platform are modeled. | HAM B: The properties and resource of the communication links (e.g., bandwidth) are modeled. | HAM C: The SW architecture (BaseSW, middleware, RTE, application SW) on an execution element is modeled. | HAM D: The properties and resources of the execution elements (e.g., CPU, RAM, ROM) are modeled. | |
| SW Architecture Modeling (SAM) | SAM A: The decomposition of the software subsystem into tasks is modeled. | SAM B: The mapping of SW tasks to elements of the execution platform is modeled. | |||
| Viewpoint | Focus Areas | Capability A | Capability B | Capability C | Capability D |
| Simulation | Time synchronous | TSY A: Simulation of deterministic time synchronous state machines. | TSY B: Simulation of composed time synchronous state machines. | TSY C: Simulation of underspecified time synchronous state machines. | TSY D: Scheduling of simulations of time synchronous state machines. |
| Timed only | TIO A: Simulation of deterministic timed state machines | TIO B: Simulation of composed time state machines. | TIO C: Simulation of underspecified time synchronous state machines. | TIO D: Scheduling of simulations of time synchronous state machines. | |
| Untimed | UNT A: Simulation of deterministic untimed synchronous state machines | UNT B: Simulation of composed time synchronous state machines. | UNT C: Simulation of underspecified time synchronous state machines. | UNT D: Scheduling of simulations of time synchronous state machines. | |
| Composed simulation | COS A: All simulations are implemented to the greatest capability |