4、需求分析与可行性研究：需求获取方法、需求建模与可行性分析

需求分析与可行性研究是系统规划与管理师在项目启动阶段的核心工作。需求分析回答“系统必须做什么”，可行性研究回答“在当前约束下能否做成、是否值得做”。两者相辅相成：需求获取的质量直接决定建模的准确性，而可行性分析则是对需求范围、技术路线和资源投入的“现实校验”。本章围绕需求获取的三大方法、需求建模的两种核心视图（用例图、数据流图）以及技术/经济/运营三维可行性分析展开，帮助学员建立从“用户意图”到“可评审方案”的完整方法链。

4.1 需求获取方法：访谈、问卷与观察

4.1.1 核心原理

需求获取是系统分析的第一步，其本质是从干系人（stakeholders）处收集、确认并整理系统必须满足的功能与非功能需求。常见误区是将需求获取等同于“用户说、我记录”。实际上，用户往往无法完整表达隐性需求，或者不同用户之间需求存在冲突。因此，需求获取需要采用多种方法交叉验证，并辅以引导、澄清和优先级排序。

4.1.2 操作流程

1. 干系人识别与优先级划分：列出所有可能影响系统或受系统影响的角色（高层管理者、业务操作员、IT运维、外部客户等），并标注其影响力和关注点。
2. 方法组合选择：根据干系人数量、地理分布、需求复杂度选择2~3种方法组合。例如：高层用访谈，一线员工用问卷+观察，外部客户用问卷。
3. 执行与记录：访谈时使用录音（需征得同意）并做结构化笔记；问卷设计包含封闭题和开放题；观察时记录时间戳、操作步骤、异常事件。
4. 需求整理与验证：将获取的信息转化为“用户需求条目”，每条需求需标注来源、优先级、状态（已确认/待确认/冲突）。

4.1.3 案例拆解：某制造企业设备报修系统需求获取

背景与约束：某制造企业有3个厂区、约2000名员工，设备报修目前通过电话和纸质工单流转，平均报修响应时间超过4小时。企业计划建设一套设备报修系统，要求在6个月内上线，预算80万元。

初始现象：项目组最初只访谈了设备部经理和IT主管，得到的需求是“做一个手机报修App，能拍照上传”。但通过后续观察发现，一线操作工在设备故障时往往满手油污，不方便操作手机；且车间网络信号不稳定。

关键输入数据：通过问卷（发放300份，回收267份）统计，78%的操作工希望报修方式“越简单越好”，65%的人希望“能电话报修或扫码报修”。通过观察发现，设备上已有二维码铭牌，但未启用。

分析判断过程：项目组调整方案，采用“扫码报修+电话IVR报修”双通道，App作为辅助管理端。同时，在需求建模时增加了“离线暂存”功能，确保网络不稳定时工单不丢失。

实际操作步骤：① 对3个厂区各选1条产线进行一周的现场观察；② 设计并发放问卷；③ 对设备部、维修班组长、操作工代表进行半结构化访谈；④ 汇总需求并绘制用例图初稿。

结果对比：调整后的方案在试点阶段报修响应时间缩短至1.5小时，用户满意度从2.8分（5分制）提升至4.2分。

复盘经验：单一需求获取方法容易产生“伪需求”。访谈适合获取战略级需求，问卷适合验证普遍性，观察适合发现真实场景约束。三种方法组合使用，才能形成完整的需求画像。

4.2 需求建模：用例图与数据流图

4.2.1 核心原理

需求建模是将文字需求转化为可视化、可评审的模型。用例图（Use Case Diagram）从用户视角描述系统功能与参与者之间的关系，适合界定系统边界和功能范围；数据流图（Data Flow Diagram, DFD）从数据视角描述数据在系统中的流动、加工与存储，适合分析数据处理逻辑和数据库设计基础。

4.2.2 判断方法与操作流程

用例图绘制步骤：

1. 识别参与者：谁直接使用系统？谁提供数据？谁接收结果？
2. 识别用例：每个参与者需要系统做什么？每个用例必须是一个完整的、可观察的功能。
3. 绘制关系：include（一个用例总是包含另一个用例）、extend（一个用例在特定条件下扩展另一个用例）、generalization（参与者或用例之间的继承）。
4. 评审：与干系人确认用例是否覆盖所有已获取的需求。

数据流图绘制步骤（分层法）：

1. 绘制顶层图（上下文图）：只画一个加工（整个系统）和外部实体。
2. 绘制0层图：将顶层加工分解为3~7个主要加工，标注数据流和数据存储。
3. 逐层细化：对复杂加工继续分解，直到每个加工逻辑清晰。
4. 检查平衡：父图与子图的输入/输出数据流必须一致。

4.2.3 实战场景：在线培训平台需求建模

某在线培训平台需要支持学员选课、学习、考试、证书发放。项目组先用用例图界定功能范围：参与者包括学员、讲师、管理员、支付网关。主要用例包括“选课”“在线学习”“参加考试”“管理课程”“处理支付”等。其中“参加考试”包含“自动阅卷”，“处理支付”扩展“使用优惠券”。

随后绘制数据流图：顶层图显示学员与平台、支付网关之间的数据交互；0层图分解为“课程管理”“学习管理”“考试管理”“支付管理”四个加工。数据存储包括“课程库”“学员库”“成绩库”“订单库”。通过DFD发现，“成绩库”需要同时被“考试管理”和“证书管理”读取，因此需要设计统一的数据接口。

该案例说明，用例图帮助项目组与业务方快速达成范围共识，而DFD帮助开发团队理解数据流转，为后续数据库设计和接口设计提供依据。

4.3 技术/经济/运营可行性分析

4.3.1 核心原理

可行性分析是在需求基本明确后，从技术、经济、运营三个维度评估项目是否值得启动。技术可行性关注“能不能做”，经济可行性关注“值不值得做”，运营可行性关注“上线后能不能用起来”。三者缺一不可，且需要综合权衡。

4.3.2 判断方法

技术可行性评估流程：① 列出所有关键技术需求（如高并发、大数据量、移动端适配）；② 评估现有技术栈的成熟度；③ 进行概念验证（Proof of Concept, POC）或原型开发；④ 评估团队技能差距，制定培训或招聘计划。

经济可行性评估流程：① 估算开发成本（人力、软硬件、第三方服务）；② 估算运维成本（云资源、人工维护、升级）；③ 量化收益（节省人力、提高效率、增加收入）；④ 计算NPV和回收期。若NPV>0且回收期在可接受范围内，则经济可行。

运营可行性评估流程：① 评估管理层支持度；② 分析用户接受度（可通过试点或原型测试）；③ 制定培训与变革管理计划；④ 确认日常运维责任方和SLA。

4.3.3 案例拆解：某银行智能客服系统可行性分析

背景与约束：某城商行计划建设智能客服系统，预算150万元，要求12个月内上线，需通过银保监会合规审查。

初始目标：将人工客服接通率从60%提升至85%，降低人工成本。

关键输入数据：现有客服中心日均话务量8000通，人工客服30人，平均每通电话成本4.5元。智能客服预计可分流40%的简单咨询。

分析判断过程：

• 技术可行性：自然语言处理（NLP）技术已较成熟，但银行场景需要定制意图识别模型。项目组进行了POC测试，准确率达到92%，满足要求。但发现需要额外采购语音识别引擎，增加成本15万元。
• 经济可行性：总成本165万元（开发120万+语音引擎15万+运维30万）。年节省人力成本：8000通×40%×4.5元×365天≈525万元。NPV（按3年、折现率8%计算）约为1200万元，回收期约4个月。
• 运营可行性：客服中心主管支持，但一线客服担心失业。项目组制定了“人机协作”方案，智能客服处理简单咨询，人工客服聚焦复杂投诉和情感沟通。同时安排培训，帮助客服转型为“质检员”和“培训师”。

实际操作步骤：① 完成POC测试；② 编制详细成本收益表；③ 组织客服中心员工座谈会；④ 形成可行性研究报告提交管理层审批。

结果对比：项目获批并成功上线。上线6个月后，接通率提升至88%，人工客服满意度反而提升（因为工作内容更有价值）。

复盘经验：可行性分析不是“走流程”，而是用数据说话。技术POC验证了可行性，经济测算提供了决策依据，运营沟通化解了组织阻力。三者缺一不可。

4.4 常见误区与总结复盘