he Software Method-001 Profit = Requirements - Design

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.