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

This article explores how to turn business modeling into valuable software requirements, using a concrete case of introducing face‑recognition payment to a school canteen. It starts by quoting the idea that "code is debt, not asset" and emphasizes that the true value of a system lies in the problems it solves for users and the organization.

It then examines common sayings about requirements (e.g., "the requirement keeps changing") and explains why many of them are misleading. The author argues that a good requirement must address a real improvement metric for the organization, not just a superficial feature.

The core of the article is a step‑by‑step framework for locating the target organization and the decision‑maker (the "boss"):

Identify the organization that will benefit most from the system.

Determine the specific person who has the authority and responsibility to approve the improvement.

Classify the scenario into one of three types (non‑customized system for a specific group, customized system for a specific institution, or non‑customized system for a class of institutions).

Applying this framework to the canteen example, the author narrows down the target to a middle‑size city elementary school where students still use physical meal cards. The envisioned improvement is to reduce the average payment time from five minutes to three minutes.

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

Next, the article discusses how to derive concrete improvement goals and metrics, such as measuring payment time reduction, cost savings from avoided hardware, or the number of credit‑like advances needed for students with insufficient balance.

It then moves to business use‑case analysis, distinguishing external value (what the organization provides) from internal processes, and stresses the importance of aligning use cases with the organization’s core value. Several diagrams (omitted here) illustrate the current and improved sequence of actions in the canteen.

Finally, the piece presents a detailed use‑case specification for the payment deduction process, covering pre‑conditions, post‑conditions, stakeholder interests, basic flow, alternative flows, field list, business rules, quality requirements, and design constraints. The specification shows how to handle situations such as unregistered accounts or insufficient balance, and proposes a controlled advance‑payment policy (e.g., up to three advances per student, each not exceeding 30 CNY).

Overall, the article demonstrates a systematic approach to turning vague business problems into precise, measurable software requirements, ensuring that development effort is focused on delivering real organizational value.