Reading Notes on 'Software Method': Business Modeling, Requirements, Analysis, and Design

The article summarizes the book 《软件方法》 (Software Method), focusing on its core methodology for software development: business modeling, requirements, analysis, and design.

It begins by stressing that developers must understand the industry they work in, and that profit equals demand minus design, highlighting the importance of getting requirements right before investing in design.

Business modeling is broken down into four steps: (1) defining a clear vision by identifying the target organization, its key decision‑maker, and a measurable improvement goal; (2) drawing a business use‑case diagram to capture the organization’s external value; (3) creating a business sequence diagram to model the current workflow and spot improvement opportunities; (4) applying improvement patterns such as turning physical flows into information flows, improving information transfer, and encapsulating domain logic.

The requirements phase follows the modeled business processes. Techniques for eliciting real stakeholder needs include interviews, questionnaires, observation, and studying competitors, while avoiding premature UML diagrams when talking with non‑technical stakeholders. The system use‑case diagram is derived from messages pointing to the system in the business sequence diagram, and each use case is refined with pre‑conditions, post‑conditions, stakeholder interests, basic and alternative paths, and supplementary constraints such as field lists, business rules, quality requirements, and design constraints.

Analysis focuses on building an analysis class diagram that separates core domain from non‑core domain concerns. Analysis classes are categorized as boundary (input/output), control (coordinates use‑case flow), and entity (encapsulates core domain data and logic). The article details how messages flow from boundary to control to entity classes, how to aggregate entities, and how to identify relationships—generalization, association (aggregation/composition), and dependency—while applying naming conventions and avoiding common pitfalls. It also introduces a “color modeling” approach using things, descriptions, time moments, and roles.

The conclusion reiterates that the true value of software lies in satisfying genuine demand; design merely enables efficient delivery. Mastering business modeling ensures that the built system addresses real organizational needs and yields lasting competitive advantage.