DEV Community: FagaoMBSE

1.2.1 Modeling Workflow ABCD

FagaoMBSE — Fri, 13 Sep 2024 13:20:46 +0000

1.2 Modeling Workflow

1.2.1 Modeling Workflow ABCD

To create good requirements and designs, and thereby produce marketable systems at low cost, it's not enough to just shout slogans. It requires patience to learn and practice necessary modeling skills.

Software development is incremental and iterative. Each iteration cycle needs to consider the following aspects in sequence:

A-Business Modeling — Identify the target organization that needs improvement and the most pressing issues that need to be addressed.

B-Requirements — Describe the overall performance that the information system to be introduced must have to improve the organization's problems.

C-Analysis — Refine the core domain mechanisms that the information system to be introduced needs to encapsulate to meet functional requirements.

D-Design — Consider quality requirements and design constraints, mapping core domain mechanisms to selected non-core domains for implementation.
This book refers to the above ABCD as the four modeling workflows of software development.

If using this book's methodology and UML notation, the ABCD would roughly look like Figure 1-5.

Figure 1-5 Four Modeling Workflows (This Book's Methodology + UML)

Various fancy terms in the software world, whether genuinely innovative or pseudo-innovative, can basically be summarized using the above ABCD, for example:

Product Manager, Requirements Engineer, Requirements Analyst: A+B+partial C.

Business Architect: Could be A (where "business" means "organization"), or C (where "business" means "core domain").

System Architect: C+D. Teams often say they want to improve system architecture, but what they actually want to improve is B-Requirements.

Domain-Driven Design: C+D. Some teams claim they want to learn "Domain-Driven Design," but what they actually want to solve is A-Business Modeling.

Microservices: C+D

Design Patterns: C+D

......

Readers are welcome to add and update at any time.

Step-by-Step Modeling of WaterDistiller Using EA and SysML (01)

FagaoMBSE — Fri, 30 Aug 2024 03:55:41 +0000

For many students learning SysML and MBSE, one of the more challenging issues is that in various tutorials, the diagrams provided are already drawn! How to start from scratch and create the model using a modeling tool is not covered in the tutorials.

Therefore, I decided to "recreate" the case study models from popular textbooks using popular modeling tools, demonstrating how to gradually model from scratch to achieve the final model of the case study.

This article recreates the case study from Chapter 16 of the book "A Practical Guide to SysML: The Systems Modeling Language, 3rd Edition", which involves a Water Distiller. The case study covers all 9 types of SysML diagrams.

Case Study Background:

A humanitarian organization is dedicated to providing pure drinking water to remote and impoverished areas, and thus wants to develop a simple and inexpensive water distiller. This distiller system does not require electricity (let alone a computer).

For a complete modeling demonstration video, visit:
https://fagao.us

The following guide uses Enterprise Architect ( EA ) version 16.0.

I. Creating the Model

Step 1.1 (Optional)

Drag the Browser window and dock it on the right side.

★ If you have just installed EA, the Browser may initially be on the left by default. My usual practice is to move it to the right.

Step 1.2

Click "click to open project" in the Browser. In the pop-up "Manage Project" dialog, click "Local File" | "New Project."

Step 1.3

In the "New Project" dialog, choose the save type as *.qea.

★ The qea and qeax formats are supported from EA version 16, using SQLite to store model data. qeax is shareable, while qea is not. The earliest save types used by EA were eap and eapx, which use the Microsoft Access database. feap uses the Firebird database. You can use EA's model transformation feature to convert between these formats.

Step 1.4

Enter the name: "WaterDistiller," and click "Save."

Step 1.5 (Optional)

Click “Start | Appearance | Preferences" | "Preferences," and in the "Themes" tab of the dialog, choose "Monochrome for printing" under "Diagram Theme."

In the "Appearance" tab, click "Default Font," and in the "Configure Default Fonts" dialog, choose your preferred font and size.

Step 1.6

Select "Model" in the Browser, and click "New Package" (the second icon from the left on the Browser toolbar). In the "New Package" dialog, enter "Distiller Project" in the "Name" field, and click "OK."

Next, we will create the package diagram for the project.

[Single Choice]The purpose of requirements work in software development is to ____.

FagaoMBSE — Sat, 17 Aug 2024 02:07:18 +0000

1 [Single Choice]
The purpose of requirements work in software development is to _.
•  A) Make the system more marketable
•  B) Better guide the design
•  C) Provide an outline description of the system
•  D) Meet the software engineering requirements specifications
2 [Single Choice]
The purpose of design work in software development is to _.
•  A) Provide a detailed description of the system
•  B) Better guide the coding
•  C) Reduce development and maintenance costs
•  D) Meet the software engineering design specifications
3 [Single Choice]
A developer says, "Based on the client's requirements, our system is divided into the Sales subsystem, Inventory subsystem, Finance subsystem...". What kind of cognitive error does this statement reflect the developer might have?
•  A) The developer has not recognized the importance of object-oriented design.
•  B) The developer is mapping requirements directly from the design.
•  C) The developer is mapping design directly from the requirements.
•  D) The developer did not use UML models to describe the subsystems.
4 [Single Choice]
When opening the requirements specification written by the developer, you find that the use case names are "Student Management," "Question Bank Management," "Course Management..." What is the biggest potential issue hidden behind this?
•  A) The names of the use cases are not in verb-object structure and should be changed to "Manage Students..." etc.
•  B) The use cases are too coarse-grained; each should be broken down into four use cases, such as "Add Student," "Modify Student," etc.
•  C) The developer is mapping design directly from the requirements.
•  D) The developer is mapping requirements directly from the design.
5 [Single Choice]
Among the following terms that are often used in development teams, which one confuses the distinction between requirements and design?
•  A) Functional module
•  B) Detailed design
•  C) User requirements
•  D) Business architecture
6 [Single Choice]
Which of the following statements about requirements and design is correct?
•  A) Requirements focus on the outline, design focuses on the details.
•  B) The purpose of requirements is to better guide the design.
•  C) The purpose of design is to break down the system into modules that can be coded.
•  D) Requirements and design are not one-to-one corresponding.
7 [Multiple Choice]
Some developers lack the ability to analyze complex domain logic, so they introduce distractions such as performance, development time, and the composition of the development team to shift the focus away from the real issue. Which of the following practices are similar to this approach?
•  A) A doctor secretly uses artificial intelligence to assist in treating a cancer patient.
•  B) A doctor tells a cancer patient, "Given your financial situation, you can only afford this drug, so this drug is the most suitable."
•  C) A doctor tells a cancer patient, "Our hospital currently only has this drug, so this drug is the most suitable."
•  D) A doctor sees that a cancer patient is in poor financial condition and only charges $80 for a drug that normally costs $8,000 per box.

"Subsystems" Are Actually Requirement Packages

FagaoMBSE — Wed, 07 Aug 2024 14:51:41 +0000

Common Mistakes 01

"Subsystems" Are Actually Requirement Packages

We often hear statements like, "This system is divided into eight subsystems, including the sales subsystem, financial subsystem, inventory subsystem..." This is an example of not distinguishing between requirements and design. In fact, the speaker might mean to say, "The functional requirements of this system are divided into eight requirement packages..."

Requirement packages are based on the stakeholder's perspective to partition the system's functions, whereas subsystems (components in UML terms) are based on the internal perspective to partition according to the coupling and cohesion of system parts. These two are not one-to-one correspondences. The so-called "financial subsystem" might actually be "putting the functions used by financial personnel into one package," as shown in Figure 1-2.

Figure 1-2 "subsystems" are actually rquirement packages

The Software Method-001 Profit = Requirements - Design

FagaoMBSE — Thu, 01 Aug 2024 03:59:09 +0000

Profit = Revenue - Cost.

To make a profit, regardless of what you're selling, two conditions are necessary:

(1) The selling price should be high;
(2) The cost should be low.

The brilliance lies in the fact that there's no fixed formula between price and cost, which is the very source of innovation.
Applied to the software industry, I've coined a formula:

Profit = Requirements - Design

Being able to develop and maintain a system at a low cost does not necessarily guarantee that it will sell well. Conversely, even if a system sells well, if the development and maintenance costs are too high, the ultimate profit will still not be substantial.

In software development, requirements work aims to solve the issue of "increasing sales," while design work aims to solve the issue of "reducing costs." Neither can replace the other. Being able to develop and maintain a system at low cost doesn't necessarily guarantee that it will sell well. Conversely, if a system sells well but has high development and maintenance costs, the final profit still won't be high.

The "profit," "sales," and "cost" mentioned above are used in a broad sense. They can refer to money, reputation, power, manpower, etc.

Even if you're making an internal system not publicly sold in the market, or even making a system for your own convenience, the above formula still applies.

More crucially: There isn't, and shouldn't be, a rigid one-to-one mapping between requirements and design. Fortunately so, otherwise artificial intelligence could easily learn these mapping patterns and replace software developers in completing all tasks. Currently, one of the values of software developers lies in their ability to select the most suitable mapping scheme from many possible options and create better mapping schemes based on their domain knowledge and software development expertise.

Let's first look at a system that has existed since ancient times: the human body.

The functions (requirements) of the human body are (the ability to) walk, run, jump, lift weights, throw, swim, etc. However, when designing the structure of the human body, it's not a direct mapping from functions (requirements) to design, resulting in "walking organ," "running organ," "jumping organ"... The organs of the human body are eyes, ears, heart, lungs, liver, stomach, skeleton, skin... These organs do not correspond one-to-one with the functions of the human body. When collaborating to fulfill the system's functions, the relationship between them and the functions is many-to-many.

Figure 1-1 the relationship between components and functions is many-to-many.

In software development, directly mapping requirements to design will result in a large amount of duplicate code, increasing costs; if requirements are defined based on design, it will lead to a bunch of fake "requirements," decreasing sales. In either case, profit will decline.
Many software developers are not aware of this point.

How Many System Use Cases Are Ideal? Just One!

FagaoMBSE — Sun, 28 Jul 2024 14:15:09 +0000

Question:

The method of transitioning from business sequence diagrams to a system use case diagram is very good. I have a question: to what extent should we make improvements, and how many system use cases are ideal?

Answer:

Strictly speaking, the number of system use cases to focus on in each iteration should always be one.
Even if, while improving the business sequence diagrams using the target system, you happen to improve many aspects and map out multiple use cases for the target system. For example, consider the following two sequence diagrams:

Sequence Diagram 1

Sequence Diagram 2

From the above two sequence diagrams, we map out System E's use case diagram:

System E Use Case Diagram

However, this is only a preliminary exploration. It doesn't mean that the system must have these use cases in the end, nor does it mean that the system only has these use cases.

You need to judge which use case should be implemented first based on the vision, then observe the results of the improvements to determine if the vision's goal have been met and if further improvements are needed. If the goal are met, you can stop; if not, continue improving.

By continuously repeating the above exploration, the number of use cases in the final system does not have a standard answer. The best answer, derived from the vision and stakeholder interests. It could be 1, or it could be 1000.

Understanding the above knowledge, you'll know how to answer similar questions like:

• Is modeling more effective for new projects?
• How does modeling differ when improving legacy systems?
• How can we ensure we've identified all the system's use cases?

These questions don't have fundamental differences.

It's similar to diagnosing a patient. A doctor examines the patient's current condition, considers the treatment plan, tries the treatment, observes the results, and repeats the process. Whether the patient has been treated by another doctor, brought medical imaging records from another clinic, or has leftover medication from another doctor, does not change this approach. If the medical imaging records or leftover medication can still be used, it just saves some money.

Is "startup software" a use case?

FagaoMBSE — Fri, 26 Jul 2024 11:42:59 +0000

Question:

Can "startup software" be considered a use case? When software starts, it typically needs to instantiate some objects, read some configuration files, etc. So, Are “start software” and “shut down software” use cases? Or are they extensions of other use cases?

Answer:

No, it is not.

Use cases are requirements. Requirements describe the necessary behaviors (functionality, performance, constraints) of a system as a whole (black box) - "it won't work without this."

Let's break it down:

(1) Is "startup software" something that stakeholders consider "it won't work without this"?

Actually, it's not.

Stakeholders are interested in the core value that our system provides. If our system could be used continuously from the moment it faces stakeholders, calculating whatever they need without requiring startup, stakeholders would be delighted. How to achieve this? It's not a matter of requirements.

(2) "Software usually needs to instantiate some objects, read some configuration files (during startup)" - this is likely not a requirement.

"Instantiating", "reading", "loading" are actually design assumptions that arise from a design perspective.

The system is a black box; there's no "instantiating", "reading", "loading". Remove these, then ask "why, what might happen without this?" The answer might be "without this, when performing certain calculations, the time from input to output might be longer, and we'd fall behind competitors" - this is what the system as a whole must satisfy.

(3) Is it relevant to the current system and current use cases?

Some might argue that the system needs to start first. However, this is universally understood and doesn't have a specific relationship with the current system or use cases, so it doesn't need to be explicitly stated as a use case.

Unfortunately, many people are inclined to treat "startup" as a use case, including it in every project without much thought. This can be an easy way to pad project documentation, but it doesn't add value.

Of course, if "startup" is the core value of the target system, then it is a use case. For example, for software that provides a “remote cross-platform application launch” service.

Is "non-functional requirement" a vague term?

FagaoMBSE — Thu, 25 Jul 2024 09:11:53 +0000

"Non-functional requirement" is indeed a vague term, but this vagueness is in expression, stemming from historical convention. Continuing to use it causes less harm than terms like "functional module" or "user requirement".

The vagueness lies in that, for the set of "requirements," "functional requirements" is a subset, and the literal meaning of "non-functional requirements" is the complement of "functional requirements." Therefore, the union of these two is the universal set. The statement "requirements are divided into functional requirements, non-functional requirements, and design constraints" is not rigorous.

However, the way of stating functional requirements + non-functional requirements + design constraints has been in use for a long time. I myself started using this expression around 2002. Of course, I must have seen it in textbooks, but I can't remember exactly which one. In fact, many books still express it this way over the years, and some are even more confusing:

Software Engineering: Theory and Practice, Shari Lawrence Pfleeger, Joanne M. Atlee, 2009

The Requirements Engineering Handbook, Ralph R. Young, 2003

Aspect-oriented software development with use cases, Ivar Jacobson, Pan-Wei Ng, 2005

To be more rigorous in expression, the approaches can be:

(1) Design constraints are not requirements.

This is inappropriate. Putting them together indicates they belong to the same category, whether it's called "requirements" or "A Cat" or "A Dog." They all fall under "the system must be this way; otherwise, it will harm stakeholders' interests."

(2) Design constraints are a kind of non-functional requirement.

This is acceptable, but conventionally, when "non-functional requirements" are mentioned, speed, reliability, etc., come to mind. This also causes the vague expression.

(3) Rename "non-functional requirements".

Such a catch-all naming as "non-functional requirements" is inherently inappropriate. For example, it can be renamed to the expression used in Pfleeger's book — "quality requirements." However, the term "quality" is also quite vague.

"Requirements are divided into functional requirements, quality requirements, and design constraints" is still not appropriate. Why do the first two end with the word "requirements" while the last one doesn't? We could remove the "requirements" suffix altogether - requirements are divided into three types: functionality, performance, and design constraints.