TABLE OF CONTENTS Marginal notes complete the approach chapter. This final section discusses a few topics that support our modeling effort, including variant management or modeling patterns, and topics such as testing that should not be left unmentioned, but which would go beyond the scope and volume of this book if I were to discuss them in detail.
Missing a topic? Or should I actually deal with a topic in more detail? I'll be happy to receive your suggestions. Please write to me: twe@system-modeling.com.
We have quickly opted for one specific solution to the requirements of our principal in our example project. The blueprint came from the principal themselves, which is absolutely the norm. The road we took makes itself notice in the model early on, e.g., in the project context or the list of stakeholders. As for the requirements, we have put in some effort to separate the purely domain-specific and essential requirements from the technical requirements (Section 2.2.2). In this section you will learn how different solution variants can be modeled. You obtain several variants if you create a model for a product family, or if you want to evaluate several solution alternatives for one system to identify the best one.
Let's begin with the requirements from the status quo where the essential requirements are separated from the technical ones. We put both areas into a package by the name of core requirements. Next, we determine the requirements that are NOT valid for...
