小南伴你学-応用情報-第7期：系统开发之面对过程与数据

type

Post

status

Published

date

Feb 2, 2026

slug

summary

小南伴你学-応用情報-第7期：系统开发之要件定義

上节课复习

阶段	日文	谁主导	说明
企画	企画	甲方	要不要做、做什么、为什么
業務要件定義	業務要件定義	甲方主导＋乙方协助	as is to be 发RFP啥的
要件定義	要件定義	甲方主导＋乙方协助	业务需求的确定
外部設計	外部設計（基本設計）	乙方主导	从用户视角设计系统
内部設計	内部設計（详细設計）	乙方	技术实现细节
开发/测试	製造・試験	乙方	实现
运用	運用・保守	甲方＋乙方	使用和维护

共通框架2013并不是一种强制性的系统开发流程，而是用于整理和说明系统生命周期各项活动的参考模型（Reference Model）。

因此，其中所描述的各个流程及其顺序，并非必须严格遵守，而应根据项目规模、组织能力及实际情况灵活应用。

比如，理想情况下，系统建设应当从甲方自身的业务课题出发，由甲方明确为什么要做、要解决什么问题，再据此推进企画和后续流程。这样可以避免系统建设流于形式，提高投资效果。

但在实际情况中，甲方并不总是能够清晰地认识自身的问题。例如，在数字化转型（DX）背景下，很多组织虽然意识到“应该做点什么”，却并不清楚具体应该做什么、从哪里入手。在这种情况下，甲方完全可以在企画之前或企画过程中，向外部供应商或咨询方发出请求，委托其进行现状分析、课题整理或立项支援，通过外部专业能力来明确方向。

Thing time

转弯的地方剪？

平均长度验一下？

甲方：

转弯的地方剪？

平均长度验一下？

乙方怎么办？

咋要件定義？

误区

❌ Hearing？

要件定義 = 听客户说 + 记下来

✅ Hearing？

要件定義 = 用技法“逼”出真实需求

客户大概率说不清自己要什么，他们只会说：

“要个像××那样的系统”

“要提高效率”

“现在这个不好用”

所以 Hearing 不是聊天，是“结构化询问和确认”。

比如5W1H：

项目	在要件定義里问什么
Why	这个问题的业务价值是什么？
What	系统必须提供哪些能力？
Who	哪些角色参与？
When	时间限制 / 频率 / 高峰？
Where	在哪发生？是否在系统范围？
How	现状流程 & 业务约束？

我自己也会问

What：将现有私有云系统迁移至 Azure，并通过容器化与托管服务运行。

Who：客户负责账号与数据，我方负责设计、构筑、迁移与运维，相关团队协同支持。

When：项目周期约 6 个月，分阶段完成设计、构筑与迁移。

Where：目标环境为 Azure（开发/本番分离），并与现有私有云专线互通。

Why：为实现系统现代化、提升运维效率与可观测性，并优化成本与安全管控。

How：通过应用容器化、分阶段部署与数据迁移，结合托管服务与 MSP 运维完成。

技法学习

很多时候业务人员与开发人员的语言是不共通的

DFD/HIPO/Flow/Decision/ = 流程和逻辑分析

UML = 系统结构和行为建模

DFD

DFD 作为业务人员与开发人员之间的共同语言，用于在需求分析阶段防止双方对系统理解产生偏差。

知识检验

直接跟我一起画

小试牛刀

小白的带狗之旅

小南要回老家，但是狗狗没人照顾，
所以把狗狗交给小白，要求小白帮忙照顾狗狗；
小白每天从冰箱里的鸡蛋喂狗；
完成后把狗狗还给小南。

怎么画？

初露锋芒

某科研项目的费用支付流程如下：系统接收项目负责人的费用收据后，查阅项目存档文件对收据进行审核；审核通过后，根据项目账目文件计算应支付的费用；计算完成后，系统将付款通知发送至财务处，并将领款通知发送给项目负责人。

请根据上述描述，画出该费用支付处理过程的数据流程图（DFD）。

哪些是Entity？（系统之外的人，组织）大主语

项目负责人，财务处

哪些是Process？（系统要做的处理）动词

审核，计算

哪些是Data store? （处理中所需的数据）

存档文件，账目文件

哪些是Data flow? （传递的数据）

费用收据，付款通知，领款通知

画

知识扩展

因为DFD是面向过程，系统简单还好，一旦系统复杂，需要采用DFD分层画法进行拆解

DFD-0

DFD-1

DFD（数据流图）主要关注系统中的数据流和数据存储，而对处理逻辑和具体操作表现不足。为了更好地表现处理过程，需要结合 HIPO（Hierarchy plus Input-Process-Output，层次输入-处理-输出图）。

可是还是没有表现出逻辑？怎么办？加Flow Chart

Decision 不光光是如果 A 然后 B,很多时候很复杂怎么办？

如果ABC那么D

決定表

決定表

不直观，怎么办

決定木

知识检验

論理模型到物理模型

論理模型

物理模型

科研项目费用支付系统 —— 物理模型

1. 系统实现方式

本系统采用 Web 应用方式实现，由业务服务器和数据库服务器组成。

项目负责人和财务人员通过浏览器访问系统。

2. 处理过程的物理实现

费用收据接收

项目负责人通过系统界面上传费用收据（PDF 或图片文件）。
系统将收据信息保存至数据库中的收据表。

费用审核

系统从数据库中读取对应项目的存档信息。
根据预设审核规则，对费用收据进行自动审核。
审核结果写入审核结果表。

费用计算

系统从项目账目表中读取项目预算与已支出金额。
通过程序计算本次应支付的费用金额。
将计算结果存入费用计算结果表。

通知发送

系统生成付款通知记录并发送至财务处系统。
同时向项目负责人发送领款通知（系统消息或邮件）。

3. 数据存储设计（示例）

收据表（Receipt）

收据编号
项目编号
上传时间
文件路径
审核状态

项目存档表（Project_Archive）

项目编号
项目负责人
项目状态
项目有效期

项目账目表（Project_Account）

项目编号
项目总预算
已支出金额

4. 系统运行环境

应用服务器：Web 应用服务器

数据库：关系型数据库

通知方式：系统消息与电子邮件

总结

该物理模型在逻辑模型的基础上，明确了系统的实现方式、处理步骤、数据存储结构及运行环境，用于指导系统的具体开发与部署。

知识检验

事象応答分析- 面对事件

事象応答分析 = 从“事件触发 → 系统响应”角度分析需求和功能，主要在需求分析和基本设计阶段使用。

事件（Event）	系统响应（Response）
用户发起取款请求	系统检查余额 → 扣款 → 更新账户 → 生成交易记录
用户输入错误密码3次	系统锁定账户 → 通知用户 → 记录日志
银行利率变化	系统更新利息计算规则 → 通知用户账户变动

状態遷移図

Petri Net

区别

状态机图

Petri net

用 Token 表示当前状态占用/资源分配

知识检验

程序切分手法

面向过程分割-关注数据流，关注动词

STS

👉STS 切分，本质上就是：把「1 个业务动词」拆成「3 个技术动词」

STS	技术动词	在干嘛
Source	接收审核	接收审核操作、审核对象
Transform	判定审核	应用规则，做判断
Sink	反映审核	保存结果、通知、更新状态