Tim Weilkiens

• CEO at oose

Cyber‐physical Systems (CPSs) are characterized by entities in both the physical and the virtual space, thus enabling an immersion of the physical world into the cyberspace. Connectivity via the cyberspace allows CPS cooperation for new services in product service systems (PSS). In consequence, cooperating CPSs act as actors with interest in the CP...

Product Line Engineering (PLE) is a fundamental component of systems engineering. As postulated in INCOSE's Vision 2025, Model‐Based Systems Engineering (MBSE) is becoming the norm for systems engineering. Thus, we need to integrate PLE into MBSE. An important aspect of this integration is the definition of model‐based methods. This paper defines t...

An engineered system is a composition of multiple entities. The existence of an engineered system is justified by purposes. The exposed system characteristics permit stakeholders to achieve these purposes. Systems are situated in their system context and may be evolved. Due to the digital revolution, a term which refers to the changes coming along...

In this chapter, the authors first discuss the organizational structure around systems architecting and then provide some recipes from their own experience for making systems architecting work in the organization. They focus on approaches that can help creating buy‐in for systems architecting on a peer‐to‐peer level. The organizational structure or...

Some people take the view that a team or project organization is Agile if it uses an iterative–incremental process for its development process. This chapter takes a look on the historical origins of the agile movement and how it was influenced. The Manifesto for Agile Software Development is a public declaration that consists of four judgmental cor...

Many systems exist in different configurations: a product line, a customized product, or different designs for trade studies. This chapter provides a brief introduction to a broad field along with a couple of ideas. The broad field of product line engineering, model‐based product line engineering, and variability management continue to evolve, and...

Architecture frameworks are very well known in the world of Enterprise Architecture development, and System of Systems Engineering (SoSE). There are a number of different frameworks for SoSE, especially in the defense domain. Enterprise can mean a small to mid‐size company, a multinational corporation, or a huge joint undertaking with a common goal...

Cross‐cutting concerns are those concerns that are relevant on different levels and layers, but also from different perspectives of the system architecture. There are very different concerns that have this nature. In this chapter, the authors discuss some of the major ones. The nonfunctional requirements are often cross‐cutting concerns, because mu...

This chapter focuses on roles without looking at the organization. A role usually goes along with a role description, defining the objective of the role and tasks, responsibilities, and competences that are related to the work to be done. Persons with the system architect role are central in system architecture. The system architect is responsible...

Defining “architecture” appears to be rather difficult considering the large number of existing definitions. These definitions share some commonality, though in detail differences become obvious. Vitruvius identified three branches of architecture: buildings, time pieces, and machines or mechanics. The importance of principles in architecture fit t...

Excellence in being a system architect depends as little on the ability of using systems engineering software tools as the excellence in being a journalist depends on skills in operating word processor software. This chapter provides some tools for the system architect to be established before taking a software tool into use: mind set, leadership,...

Requirements engineers capture requirements in direct dialogue with people or entities they call “stakeholders” or “stakeholder representatives” in a requirements engineering context. This chapter covers stakeholders that are often encountered for typical systems‐of‐interest. It discusses the role of requirements engineering as an architecture stak...

It can be advantageous to accompany the systems architecting activity with a model. Too extensive modeling is what we also call over‐modeling. Over‐modeling usually leads to an explosion of cost, which cannot be justified by the much slower evolution of benefits. It is therefore extremely important to make the cost‐benefit analysis before starting...

This chapter presents an example: the scalable observation and rescue system. The example shall be based on one single system with one single purpose, but extensible to be explored in scenarios involving the interaction of multiple systems for a purpose different from the one of the original single system. Single‐purpose system is based on the very...

Digital engineering will be the enabling technology to enable digital threads and digital twins, which in turn pave the way for the use of artificial intelligence technologies. Model‐based engineering (MBE) is a kind of digital engineering combining product lifecycle management and model‐based systems engineering approaches. The abstract syntax def...

In this book, the fictitious “Scalable Observation and Rescue System” allows for studying today’s systems architecting challenges with artificial intelligence inside the system‐of‐interest. Artificial intelligence however is expected to break out of the boundaries of such systems under development, also conquering the systems used for system develo...

The systems architecting processes are the core processes for the system architect. The actual process for producing the system architecture description consists of doing the architecting and validating or reviewing and approving its output. The system architect has to ensure that the system architecture considers each life cycle stage of the syste...

Architecture descriptions provide substantial benefit for maintenance and evolution of systems. Architecture descriptions shall document how selected solutions satisfy requirements or address concerns. Architecture starts to exist as initial solution hypothesis while analyzing and validating business and stakeholder requirements. System architects...

The functional architecture is often mentioned in publications about systems engineering or in the context of real system projects. This chapter describes Functional Architectures for Systems (FAS) and begins with the terminology and motivation of functional architectures. The FAS method is a practice‐proven method based on common model‐based syste...

Patterns and principles are documented best practices and proven experiences of system architects. Architectural principles describe guidelines that, in general experience, lead to good architecture when followed, while patterns describe basic working solutions for given problems. The functional architecture for systems method can be used to create...

The system architect and other architecture stakeholders like to see appropriate architecture views that describe the architecture of the system‐of‐interest. The architecture viewpoints take the role of defining the expectations toward the model, by defining the questions the model should answer via the architecture views. A very simple and abstrac...

In this chapter, the authors give a brief description of requirements engineering and use case analysis. They define the most important requirements and use case terms. The authors present the requirements and use case analysis methodology steps of the “Systems Modeling Toolbox” (SYSMOD). The SYSMOD methodology defines common methods and is not spe...

Architecture assessment methods assess the quality of architecture. The Architecture Trade‐off Analysis Method (ATAM) is mentioned in the standard as an example for an architecture evaluation framework. ATAM leads to an explicit consideration of the system objectives, related quality attributes, architectural approaches, and decisions. ATAM mainly...

A prosperous enterprise brings people together and creates an environment of good cooperation and appreciative togetherness. There are numerous publications and books about soft skills, discussing their importance and suggesting ways how to improve those skills. The internal communication within an organization refers mainly to the communications b...

Systems architecting will ensure that the interactions between components are controlled in a proper way and that components are designed to fit each other. When talking of better products, then “better” can have two different meanings: more satisfying or even more enjoyable for customers, and more profitable for the organization. Systems architect...

Model-Based Systems Engineering (MBSE) is an effective and efficient approach to implement systems engineering. Storing valuable system information in models increases the consistency, traceability, and availability of the information. Early validation and testing of system information enable timely feedback on requirements and design decisions. Ma...

Storyboards sind ein bekanntes Mittel der Systemanalyse. Ziel dieses Beitrags ist die Ermöglichung ihrer Nutzung im Kontext der modellbasierten Systementwicklung. Motiviert durch den Bedarf nach der Identifikation sogenannter Anwendungsfallaktivtäten für die Durchführung der FAS-Methode wird eine neue Methode (SAMS-Methode) zur Nutzung der Storyboa...

Mitglieder der Gesellschaft für Systems Engineering e. V. haben in diesem Buch – in leicht verständlicher Form und mit vielen Abbildungen und Quellenangaben versehen – zentrale Grundlagen zum Systems Engineering beschrieben. Ziel des Systems Engineerings ist die erfolgreiche Gestaltung und Realisierung von komplexen Produkten sowie die Organisation...

Appropriate communication with people from business departments is an essential success factor for BPM experts. Therefore it is necessary to establish a basic understanding of the vocabulary of concepts that they use. This chapter provides a rough overview of topics like management competencies, business strategy, market segmentation, SWOT analysis...

This chapter gives you an overview about the OMG Certified Expert in Business Process Management (OCEB) certification program. It discusses the goals of certifications in general and lists certification programs similar to OCEB.

This chapter briefly describes industry reference models, and quality, metrics, and governance frameworks to allow the reader to demonstrate awareness of a range of industry frameworks. Examples are American Productivity & Quality Center (APQC) Process Classification Framework (PCF), Supply Chain Operation Reference (SCOR) Model, Six Sigma, Balance...

A descriptive model of a whole enterprise consists of vision, mission statements, goals, strategies, and realizing tactics, among other things. The OMG business motivation model (BMM) provides a structure by means of which those terms can be kept apart. Hence it ensures clarity in creating an enterprise model. This chapter explains the main feature...

This chapter includes full exam material of BPMN modeling concepts and modeling skills based on OMG's BPMN. Definitions, symbols, and syntax of activities, gateways, events, artifacts, pools, and lanes are described. Furthermore this chapter contains how to use sequence flows and message flows in Business Process Diagrams.

This chapter is about the history and the different approaches of business process management with a focus on Total Quality Management (TQM) and Business Process Reengineering (BPR). Another aspect covered in the chapter is the concept of process-oriented organizations.

This chapter discusses the different definitions of the term business process. It describes the common properties of a business process and the different abstraction levels of business process descriptions.

SYSMOD is an MBSE toolbox for pragmatic modeling of systems. It is well-suited to be used with SysML. The book provides a set of methods with roles and outputs. Concrete guidances and examples show how to apply the methods with SysML. * Requirements modeling * System Context * Use Cases * Functional, Physical, Logical and Product Architectures...

Im Frühjahr 2016 endete das ZIM-Kooperationsprojekt Functional Architectures of Systems for Mechanical Engineers (Arbeitstitel - kurz „FAS4M“). In dem 30 monatigen Forschungsprojekt wurde ein modellbasiertes Vorgehen für mechanische Anteile eines Systems erarbeitet. Hierbei lag der Fokus auf der konzeptionellen Arbeit, welche z.B. nach dem Erstelle...

The objective of Model-Based System Engineering (MBSE) is to provide the right tools to create and manage all life-cycle information in a pragmatic, concise, consistent and traceable way across the numerous perspectives and architectural levels. Its practical use, however, is currently impeded by a universal lack of experience and integration with...

SysML does not provide explicit built-in language constructs to model variants. Nevertheless SysML is useful to create a model for variants. The VAMOS method presented in the book Variant Modeling with SysML is one option how to model variants with SysML. It uses the profile mechanism of SysML to extend the language with a concept for variant model...

SYSMOD is a MBSE toolbox for pragmatic modeling of systems. It is well-suited to be used with SysML. The book provides a set of methods with roles and outputs. Concrete guidances and examples show how to apply the methods with SysML.

Ein Systementwurf kann durch die formale Beschreibung des Systems mit Hilfe der SysML (systems modeling language) erfolgen. Aber, der Entwurf sicherheitskritischer Systeme kann derzeit nicht vollständig abgedeckt werden, da die Bewertung der Systemsicherheit noch nicht explizit durch die SysML unterstützt wird. Mit Methoden wie der FMEA oder der FT...

Stakeholders in the context of system architecture are the main focus of this chapter. Each section in the chapter is dedicated to one typical architecture stakeholder inside a typical organization and the organizational interface to the system architect. The chapter describes the collaboration between the system architects and the selected stakeho...

The authors are convinced that research around product line engineering will provide even more efficient product line approaches than we know today. In this chapter, they draw out a scenario that should start a debate about the advantages and disadvantages of product line engineering. The authors suggest the reader to challenge the current systems...

The discipline model-based systems engineering (MBSE) has become very famous in systems engineering in the last years. This chapter presents the three features of a model as defined by Stachowiak in his book about general model theory. The authors second the features of Stachowiak and add some more to give a definition of how they understand and us...

This chapter focuses on the definition of system architecture. The term ?architecture? origins from ?architect?, the role that realizes the architecture of something. The process of architecting leads from requirements to one or more designs that satisfy the requirements. The design of a system comprises system elements. The term ?architecture? is...

This chapter describes the various perspectives that can be used as a means of grouping or categorizing system architecture views. The functional perspective of system architecture allows for describing the complete system conceptually, even if some implementation details are not yet known. System architecture may consist of the base architecture l...

Architecture assessment methods assess the quality of an architecture. The chapter presents an architecture assessment method, the architecture tradeoff analysis method (ATAM), which is based on a structured communication process to incorporate all relevant stakeholders and viewpoints. It focuses on the main important aspects, incorporates stakehol...

Architecture frameworks are about the description of architectures. In practice, architecture frameworks are very well known in the world of enterprise architecture (EA) development, and system of systems engineering (SoSE). This chapter first discusses the term EA, and afterward, takes a look at the noteworthy characteristics of an SoS. EA develop...

Cross-cutting concerns are those concerns that are relevant across different levels, layers, and perspectives of the architecture. This chapter discusses some of the major ones. Finally, trade studies and budgets are discussed as a means of handling cross-cutting concerns. Often nonfunctional requirements are cross-cutting concerns, because many pa...

This chapter briefly describes the requirements and use case analysis. The authors follow the “Systems Modeling Toolbox” (SYSMOD) for SysML. The methodology uses common methods of requirements and use case analysis. The core tasks include: Identify and define requirements; Specify the system context; Identify use cases; Describe use case flows; and...

This chapter describes Functional Architectures for Systems (FAS), beginning with the authors' view on the terminology and motivation of functional architectures. The FAS method is a practice-proven method based on common MBSE practices. Model-based functional architecture descriptions model systems independent of their target technology, by means...

The systems architecting process is the core process for the system architect. This chapter illustrates how the inputs and outputs of the process as well as the contributing roles could be defined. The system architect has to ensure that the system architecture considers each life cycle stage of the system and its evolution. After making a very gen...

This chapter talks about a Virtual Museum Tour system (VMT). In this system one user can log in for controlling the robot via a web application on a computer or a hand-held device, like a smart phone. The system-of-interest is composed of the robot itself together with the infrastructure and remote control software that is needed to operate it. The...

When agile approaches are implemented partly and differently in different entities of the organization, the system architect will be affected by the differences, being a multidisciplinary agent who has to collaborate with multiple entities inside the organization. This chapter aims at showing the real-world situation of system architects today, arc...

The only purpose of an architecture description (AD) is to explain the architecture of a system to its stakeholders. An AD shall document how a certain design satisfies stakeholder requirements or even stakeholder needs. The AD supports an architect in communication with stakeholders about the system of interest. It documents both, rationales and a...

Introducing system architecture in an organization is an organizational change process. A continuous organizational roll-out of the methods and the mindset of systems architecting is required from those who are convinced that systems architecting is one of the enablers for success. This chapter first discusses the organizational structure around sy...

Many systems exist in different configurations: a product line, a customized product, or different designs for trade studies. Typically, a single variant of a system affects only a few parts of the system. This chapter first presents some definitions and then describes a concept for variant modeling with SysML. SysML is useful to model variants and...

This chapter provides a broad overview about some essential parts of soft skills, and enables the reader to learn about some models from communication psychology and personality typology that are helpful to explain several interpersonal dealings and processes. It highlights the importance of communication in systems engineering projects, and discus...

Patterns are good tools to make the implicit knowledge of the system architect explicit. Patterns and principles are documented best practices and proven experiences of system architects. The pattern is described as part of the SYSMOD methodology. It describes the relationship between requirements and architectures on different abstraction levels....

Systems architecting is an approach that will help an organization think, develop, produce, and maintain better products. It produces well-founded trade studies, because it is right in between the requirements analysis work and the solution space that is framed by the development of different system elements. Systems architecting can enable a top-d...

To avoid the need to consider different kinds of organization, the notion of a role is being used. A role usually goes along with a role description, defining the objective of the role as well as tasks, responsibilities, and competences that are related to the work to be done. This chapter focuses on roles without looking at the organization. It de...

The complexity of innovative products is increasing through interaction and interdependency induced by mega-trends such as the " Internet of Things " , " Smart Manufacturing " and " Industrie 4.0 ". Multiple engineering disciplines must be well coordinated to cope with the challenge; both organization and technology are affected. In this context, o...

Nach der sogenannten FAS-Methode können funktionale Architekturen systematisch aus Anwendungsfällen hergeleitet werden. In diesem Beitrag werden die Erkenntnisse aus der Anwendung der Methode in vier verschiedenen Industrieprojekten zusammengetragen und ausgewertet. Anhand der Ergebnisse werden unter anderem Aussagen über den Umfang der Arbeit...

Das Forschungsprojekt FAS4M hat die Entwicklung eines Ansatzes zur Verknüpfung von abstrakten Funktionsmodellen mit gestaltbeschreibenden 3D-CAD-Modellen zur Unterstützung der durchgängigen modellbasierten Systementwicklung zum Ziel. Hierfür wird eine auf SysML aufsetzende Sprache (MechML) für die logische Konzipierung eines zu entwickelnden S...

Functional architecture enables the description of systems independent of their technology. A method for obtaining functional architectures for systems (the FAS method) is introduced. It provides a well-defined procedure for deriving functional architecture from use cases by using heuristics for grouping functions and allocating them to functional...

This chapter explores and describes business processes in a general way. The general question of what a business process is cannot be answered easily because there is no uniform definition. And it is important to have a uniform understanding of the meaning of the term business process, not only in the certification program but also in real life. Th...

This chapter explores definitions, symbols, and syntax of the Business Process Modeling Notation (BPMN). The current notation for business process modeling includes three main notations: the EPCs (Event-Driven Process Chains), UML (Unified Modeling Language), and, more recently, BPMN (Business Process Modeling Notation). Currently, BPMN Version 2.0...

This chapter discusses frameworks and basic terms from this area such as quality or regulation, principle, and guideline. OCEB Fundamental comprises frameworks on processes, quality, management, and metrics, as well as regulations. In the concrete project environment, there may be other frameworks that are of relevance. Process frameworks are refer...

The chapter aims to take an objective look at the pros and cons of certifications. It also explores the OMG Certified Expert in Business Process Management (OCEB) certification and its contents of the Object Management Group (OMG). The arguments in favor and against certifications are representative for certificates with automated tests without any...

The Business Motivation Model (BMM) provides a structure for defining and developing a business plan by describing which purposes an enterprise pursues by which means. The BMM is an OMG standard and describes, on the one hand, the goals of an enterprise with a superior vision and, on the other hand, the associated implementation strategies and tact...

This document provides modeling patterns, recipes, guidelines, and best practices for the application of SysML. The presented examples are rather methodology independent and can be used (maybe with some adaption) in any MBSE environment. Furthermore, it provides additionalexplanation on SysML syntax, semantics, and concepts. It partially annota...

The OCEB Certification Guide is the only official study guide to help BPM practitioners and those entering the field pass the OCEB Fundamental exam. This book offers full coverage of the exam material for both the business and technical tracks. It explains and builds on basic concepts, includes sample test questions for practice, and provides detai...

The SE^2 Challenge team created comprehensive SysML models and established modeling guidelines and conventions for all system aspects, hierarchy levels, and views by reverse engineering existing documentation of the Active Phasing Experiment (APE). In the course of SE^2's work several challenges to SysML were identified, analyzed, and the proposed...

UML had originally been developed to create models for software systems. The word unified stands for the claim that the language can be used for software systems of a large number of different domains—from business and economics systems to the development of standard software products to technical systems, such as an airbag control. UML is extensib...

Systems Modeling Language, or SysML, defines several elements to describe and model requirements, such as response times, size, or functions of a system, which means that it closes a gap in UML. While functional requirements can be modeled with use cases, there is no element in UML to explicitly describe non-functional requirements. An allocation i...

Systems engineering integrates all disciplines and describes a structured development process, from the concept to the production to the operation phase and finally to putting the system out of operation. It looks at both technical and economic aspects to develop a system that meets the users' needs. The SIMILAR process model provides a good overvi...

This chapter introduces the SYSMOD approach for modeling of complex systems. It begins with the project context, looking at our system as a black box, studying the environment, and then successively delves into the details. This approach corresponds to a widely used pattern: identify an element, describe some context (external view), and then immer...

This chapter describes the stereotypes that form the SYSMOD engineering profile required for the SYSMOD approach. The SYSMOD profile is generic, forming a good starting platform for the project-specific profiles. The SYSMOD profile defines several stereotypes for discipline-specific elements. An external system is a system that interacts directly w...

This chapter discusses unified modeling language (UML) and its history, the UML metamodel, and UML compliance levels. It also provides a brief description of the three levels of the UML certification program. UML covers a wide range of applications and is suitable for technical systems and so-called commercial systems such as socially embedded info...