关键数据与行业信号
先用公开资料确认行业变化，再以企业自身数据设定目标值和验收线。
行业变化：软件建设速度提高，需求歧义成为更昂贵的瓶颈
先看中国市场与制度环境。工业和信息化部在《2025年软件业运行情况》中明确：2025年软件业务收入同比增长13.2%，信息技术服务收入增长14.7%。因此，数字化项目需求梳理方法首先要把数字化项目需求梳理的对象和口径讲清楚。
国内资料还需要交叉阅读：全国标准信息公共服务平台资料显示，从功能适合性、性能效率、兼容性、易用性、可靠性、安全性、维护性和可移植性描述质量；全国标准信息公共服务平台资料显示，从组织、制度、过程和技术等方面评估数据管理能力。前者用于判断业务对象建模，后者用于核对角色权限。
为了检验业务对象建模，本文参考ISO/IEC/IEEE《ISO/IEC/IEEE 29148:2018 Requirements engineering》：规定需求工程过程、需求信息项及其生命周期管理。其适用对象与中国企业不同，数字化项目需求梳理方法最终采用全国标准信息公共服务平台要求，并由数字化项目需求梳理实测结果支持。
2025年中国软件业：收入与细分领域增速
软件业务收入同比增长13.2%，信息技术服务增长14.7%，集成电路设计增长18.9%；增长背景不等于单个数字化项目天然具备回报。
查看图表数据与统计口径
按工信部2025年全年运行数据重新制图；细分领域规模与统计边界不同，增速仅用于观察行业结构。
为什么从页面清单开始，需求容易越做越乱
“需要一个首页、一个列表、一个详情、一个审批页面”看似具体，实际没有说明系统管理什么、谁负责、业务如何结束。页面很快就能画出来，但当多个角色对同一数据有不同权限，或对象在不同状态下可执行动作不同时，原有页面清单会不断增加例外。
页面是用户与业务规则交互的界面。只有先把业务对象和状态关系讲清楚，页面才能稳定；否则每次评审都在讨论按钮位置，真正影响运行的责任和异常却被推迟到开发阶段。
需求分析的核心不是收集所有人的页面愿望，而是建立一套能够解释业务运行的共同模型。
第一步先锁定业务目标、范围和决策指标
需求访谈中常出现“提升效率”“统一管理”等宽泛目标。需要继续追问：现在什么环节最耗时，错误在哪里发生，哪个角色需要更快做出什么决策，首期上线后通过什么事实判断改善。
目标应与首期范围绑定。例如，“让项目申报到评审全过程可追踪”比“建设综合管理平台”更容易确定对象、角色和验收条件。目标之外的想法可以进入后续清单，但不应在首期无边界扩张。
现状问题
用真实业务事件描述耗时、错误、断点和责任不清。
目标结果
明确希望哪一段业务发生什么可观察变化。
首期边界
确定包含哪些对象、角色、组织和关键流程。
验收事实
定义可以通过数据、状态或业务记录验证的结果。
第二步识别业务对象，并给每个对象建立“身份证”
业务对象是系统长期管理的核心实体，例如项目、赛事、课程、订单、合同、设备、商户、用户或权益。每个对象都应有唯一标识、关键属性、归属组织、创建来源、生命周期和与其他对象的关系。
对象之间的关系比字段更重要。一个项目是否属于某项赛事，成果由哪个项目产生，评审记录对应哪个申报版本，这些关系决定后续查询、统计与审计能否成立。
第三步把角色、数据范围与状态动作放在一起设计
“管理员”不是一个足够清晰的角色。总部管理员、院系管理员、项目负责人和评审专家即使都能进入后台，可查看的数据范围、可执行动作和承担责任也不同。角色描述“能做什么”，组织和数据范围描述“能对哪些数据做”。
状态机用于描述对象怎样从开始走向结束。每个状态要明确进入条件、允许动作、责任角色、输出记录和退出条件。退回不是简单回到上一步，还要说明退回后哪些内容可修改、再次提交是否生成新版本、原审批意见是否保留。
第四步把异常路径提前写进需求，而不是上线后靠人工解释
- 对象重复创建时如何识别、合并或保留，已经进入流程的数据能否删除。
- 责任人离职、组织调整或角色变化后，待办和数据权限如何转移。
- 审批超时、多人意见冲突、材料缺失或外部系统不可用时怎样继续。
- 已通过结果需要变更时，是回退原流程、创建变更单，还是生成新版本。
- 跨系统同步部分成功时，哪个系统保留最终状态，谁可以发起重试或补偿。
- 历史数据迁移后缺少字段或状态时，怎样标记可信程度并避免误用。
需求阶段应交付一套可验证的业务模型
掌触如何开展复杂业务系统的需求建模
项目、赛事、课程与多角色流程需要统一业务模型
截至 2026 年 9 月，掌触科技与中国科学技术大学的相关合作自 2022 年延续至今。双创平台涉及项目、赛事、课程、成果及多角色管理等场景。此类系统的关键不是堆叠页面，而是建立对象关系、角色范围和流程状态。掌触在项目启动阶段结合成熟产品、开放集成和专属建设能力，先完成业务建模，再确定首期交付边界。
常见问题
需求访谈应该先问业务还是先看现有系统？
两者都要看，但先用业务目标和真实事件建立主线，再核实现有系统如何承接、哪里存在断点，避免被旧页面结构限制。
业务对象和数据库表是一回事吗？
不是。业务对象是业务共同语言，可能由多张表实现；需求阶段重点明确其身份、关系、状态和责任，不必过早绑定技术表结构。
角色和权限怎样避免越做越复杂？
分开描述角色能力、组织层级和数据范围，再按状态定义允许动作，避免为每个特殊人员单独创建新角色。
状态机需要细到什么程度？
应覆盖关键业务决策、责任转移和需要留痕的节点；纯技术中间状态可以在设计阶段补充，不必全部暴露给业务用户。
首期需求如何控制范围？
围绕一个可闭环目标，优先纳入必须共同运行的对象、角色和状态；无法影响首期结果的扩展能力进入后续路线图。