From Business Modeling to Requirement Specification: A Case Study of Face‑Recognition Payment in School Canteens

The article begins by emphasizing that code is a liability and that true value lies in solving product problems, quoting "Profit = demand - design" to highlight the need for minimal code that delivers maximal value.

It then introduces a series of familiar sayings about architecture and sets up a structured agenda: familiar phrases, business modeling, requirement formulation, a brief summary, and a conclusion.

In the business modeling section, the author presents a real‑world scenario: observing long queues at a school cafeteria and proposing the introduction of face‑recognition payment to improve efficiency. The vision is defined as reducing average payment time from five minutes to three minutes.

The target organization is identified through a three‑step process: first determining the appropriate user group (e.g., middle‑size city elementary schools), then pinpointing the specific institution, and finally locating the decision‑maker (the cafeteria’s logistics manager). A table illustrates three types of target organizations: non‑customized systems for specific user groups, customized systems for particular institutions, and non‑customized systems for a class of institutions.

Using the case study, the author derives a concrete goal:

目标组织：A市第一小学餐厅
老大：A市第一小学餐厅后勤管理处李处长
目标（度量指标）：平均每人就餐支付时间从5分钟缩短至3分钟

The article stresses that goals must be measurable and aligned with stakeholder interests, providing examples of comparison, specification, and reverse‑engineering methods to quantify improvements.

Subsequently, the author discusses business use‑case analysis, distinguishing external (value‑oriented) and internal (system‑oriented) perspectives, and presents sequence diagrams to capture current and improved processes.

Improvement strategies are explored, including converting logistics to information flow, enhancing information exchange, and encapsulating domain logic (e.g., automatic OTP extraction). The "Abu thinking method" is introduced to imagine ideal solutions and adapt them with existing resources.

Finally, the article details how to write a complete use‑case specification, covering pre‑conditions, post‑conditions, stakeholder interests, basic flow, alternative flows, field lists, business rules, quality requirements, and design constraints. An example specification for the payment deduction use‑case is provided, illustrating how to capture all necessary details for developers.

The piece concludes by reiterating that disciplined business modeling and requirement analysis enable teams to understand why a feature is needed, setting the stage for subsequent analysis and design phases.