📖 第2章 结构化分析（第1-2课时）：问题定义与可行性研究

🎯 【教学目标与核心降难策略】

教学目标： 掌握将模糊的用户需求转化为规范模型的能力，明确“要解决的问题是什么”以及“是否有行得通的解决办法”。

降难策略： 摒弃枯燥的理论定义，引入贴近校园开发场景与现代 Web 架构的“双主线项目”贯穿始终。用“视觉原型”和“算账”代替“长篇大论”，通过真实业务场景推演软件工程的第一步。

生活隐喻： 🗺️ “寻宝航海隐喻” —— 问题定义 是画出宝藏的具体经纬度（明确目标）；可行性研究 是评估你有多少干粮（经济）、船只抗风浪能力如何（技术）、航线是否属于他国领海（法律）。

---

2.1 问题定义：做“正确的事”远比“正确地做事”重要

在软件工程中，最灾难性的失败不是代码写得很烂、页面经常崩溃，而是完美地实现了一个用户根本不需要的系统。对于刚接触工程项目的同学（比如准备做毕设），大家往往急于打开编辑器开始写 Vue 组件，却连系统到底要给谁用都没想清楚。

2.1.1 为什么问题定义是生死线？ (Why > How)

问题定义 阶段必须极其客观地回答一个灵魂拷问：“我们要解决的根本痛点是什么？” 如果没有这个清晰的方向，后续所有的代码产出都是在浪费资源。

请看下方经典的“需求传递偏差”模型，它展示了如果不做深入的问题定义，项目是如何一步步走向深渊的：

⚠️ 【工业级坑点：把“手段”当“目标”】

这是新手最易犯的错。比如客户说：“我要一个基于 Vue3 和 ECharts 的炫酷数据大屏”（这是解决手段）。作为工程师你要多问一句“为什么”。真正的目标其实是：“院领导需要实时监控各班级的挂科率和就业率变动，以便调整教学计划”。只有找准目标，才能界定系统的边界。

2.1.2 工业级问题定义：5W1H 分析法

在撰写《问题定义报告》时，我们不能记流水账，必须按照行业规范的 5W1H 框架来约束思维：

• Who（谁）：系统的最终使用者是谁？（是普通学生，还是拥有超级权限的系统管理员？）
• What（做什么）：系统主要解决什么核心业务？
• Where（在哪里用）：运行环境是什么？（是纯移动端的微信小程序，还是 PC 端的 Web 浏览器？）
• When（时间节点）：项目的截至线（Deadline）是哪天？
• Why（为什么做）：做这个系统的核心驱动力是什么？（为了省钱、提高效率还是满足合规要求？）
• How（怎么做）：初步的技术路线设想是什么？

2.1.3 贯穿本章的双线实战项目背景

为了让大家不再在不同的虚构案例中迷失，接下来的所有知识点，我们都将围绕以下两个大家在毕设时极大概率会遇到的真实项目展开推演：

📌 【项目 A：轻量级在线教学文档与个人博客站点】

• 发起背景： 老师每次上课都要用 U盘拷贝 PPT，学生课后复习找不到资料，且传统 Word 教案缺乏代码高亮，排版混乱。
• 核心目标： 建立一个排版优雅、支持 Markdown 极速渲染、且随时可以在线访问的纯文档类站点。
• 业务特点： 重前端展示（静态资源为主），无复杂的后端数据库读写，并发访问量较小。

📌 【项目 B：高校综合教学与作业管理系统】

• 发起背景： 现有的微信群收作业方式极易漏交，辅导员无法批量导出成绩进行分析，且期末答辩时提交文件的并发量经常导致旧服务器崩溃。
• 核心目标： 打造一套包含角色权限控制（超级管理员/教师/学生）、在线作业上传与批阅、成绩多维度可视化的前后端分离系统。
• 业务特点： 业务逻辑极度复杂，对数据的安全性（防篡改）和一致性要求极高。

---

2.2 可行性研究：谋定而后动的三维评估

在明确了“要解决什么问题”后，下一步绝不是马上建 MySQL 数据库表或写前端路由，而是做 可行性研究。

它花极小的成本去探路，核心只回答一个问题：“对于刚才确定的问题，我们现有的团队和资金，有行得通的解决办法吗？” 简单来说，就是评估这事儿“能不能干”、“会不会亏本”。

2.2.1 可行性评估的核心架构图

2.2.2 深度穿透：双项目的可行性全景对比与算账实操

让我们将 项目 A（轻量课件站） 与 项目 B（教学管理系统） 放入这套评估模型中，大家会看到截然不同的评估结论。这里我们重点引入大家在实际开发中必须面对的技术栈选型与云服务账单概念。

🛠️ 维度一：技术可行性 (Technical Feasibility)

评估我们团队的“金刚钻”能不能揽这趟“瓷器活”。

• 项目 A 评估 极低风险：完全可以使用类似 VitePress 或 VuePress 这类成熟的静态站点生成器。只要具备基本的 Markdown 书写能力和 Vue 基础语法，几天即可搭建完毕，无需掌握复杂的数据库和微服务知识。
• 项目 B 评估 极高风险：要求团队具备全栈能力。前端需要熟练掌握 Vue 及其生态（如 Vue Router、Pinia）；后端通常需要引入成熟的权限管理脚手架（如 Ruoyi-Vue-Plus，涉及 Java 和 Spring Boot）。此外，为了应对期末几百人同时交作业的高并发，团队必须有人懂 Docker 容器化部署和 Redis 缓存技术。如果团队没人懂这些，项目必定烂尾。

💰 维度二：经济可行性 (Economic Feasibility)

这绝不仅仅是算程序员的工资，在现代 Web 开发中，云端基础设施的部署成本往往是压垮小团队的最后一根稻草。

• 项目 A 评估 几乎零成本：纯静态的前端资源可直接托管在 Cloudflare Pages 或 Vercel 等海外 Serverless 平台上。它们提供免费的高可用全球 CDN 加速，开发者连买服务器的钱都省了。唯一可能的花费是花几十块钱买个域名（比如 .top 或 .tech 结尾的平价域名）。
• 项目 B 评估 重资产投入：这是一个极度耗钱的“重武器”。
  • 服务器成本：由于包含了 MySQL 数据库和后端运行环境，必须购买云服务器（如腾讯云、阿里云）。这里有一个巨大的坑：许多同学只看新用户首单优惠（可能只要几十块一年），却忽略了次年高达大几百甚至上千元的续费成本。
  • 合规时间成本：国内服务器必须绑定域名并进行 ICP 实名备案，这个审核周期通常需要 10-20 天，这极大地影响了项目上线的“时间可行性”。

⚖️ 维度三：法律可行性 (Legal Feasibility)

技术人员最容易忽视的红线。

• 项目 A 评估 安全可控：内容均为原创或引用的教学资料，只要注明出处，几乎不涉及法律风险。
• 项目 B 评估 高危盲区：系统内将存储大量学生的身份证号、真实姓名和私人联系方式。如果数据库由于弱密码或无防御措施被黑客攻击导致数据泄露，开发团队需承担《网络安全法》相关的严重法律后果；此外，如果项目要拿去进行商业化售卖，必须严查所用的第三方组件是否采用 GPL 等具有传染性的开源协议（要求衍生代码也必须开源）。

---

2.3 需求获取的现代路径：从“猜盲盒”到“眼见为实”

在通过了可行性评估，老板或导师拍板说“这个项目可以做”之后，系统分析师需要极其精准地提取出“为了解决痛点，系统具体需要提供哪些页面、字段和按钮”，这就进入了 需求获取 阶段。

2.3.1 经典需求获取方法的“现代化”实操

教科书上通常会列出访谈法、问卷调查、实地观察等方法。对于现代 Web 开发而言，我们需要将这些老方法赋予新的工程意义：

• 问卷调查法 广度寻主观：适用于收集大基数用户的主观偏好。
  • 实战应用（项目 A：课件站）：你不知道课件网站的主题色该用什么，或者不知道学生平时是用手机看课件多还是用电脑多。发一份问卷给 200 个学生，如果 80% 用手机，那么你的前端开发核心需求就是：必须优先保证 移动端响应式适配。
• 实地观察与文档分析法 深度挖客观：不要听用户怎么说，要看用户怎么做。
  • 实战应用（项目 B：教学系统）：辅导员说“我要一个收作业的系统”。不要立刻去写代码，你应该去观察她现在是怎么收作业的。你拿到她平时用的那张密密麻麻的《期末成绩汇总 Excel 表》，这张表里的每一列表头（学号、姓名、平时分、期末分、是否旷考），就是你未来 MySQL 数据库里那张表最精确的字段定义！

2.3.2 角色扮演与业务流推演 (逼出异常需求)

传统的“发调查问卷”往往对复杂业务毫无作用，因为用户“不知道自己想要什么，直到你把做好的东西放在他面前”。现代软件工程提倡通过“业务流推演”来逼出真实需求。

以 项目 B（教学管理系统） 的【学生交作业】模块为例，我们看看优秀的系统分析师是如何通过对话挖掘深层前端与后端需求的：

通过这种一问一答的边界测试，我们把模糊的“传个文件”变成了一系列严谨的前后端工程化需求。

2.3.3 快速原型 (Rapid Prototyping)：终结沟通内耗

在现代敏捷开发中，直接给客户扔过去几十页全是专业术语的《需求规格说明书》，注定会引发后期的无尽扯皮。前端工程师最有效的武器是 快速原型。原型可以分为三个层级：

1. 低保真原型 (Wireframe)：直接在纸上画草图，或者用软件拖拽出纯黑白的线框图，只确定按钮位置和页面跳转逻辑。
2. 高保真原型 (Hi-Fi Prototype)：使用 Figma 等 UI 软件，做出带有真实颜色、阴影，甚至点击能够跳转的精美假页面。
3. 代码级原型 (脚手架生成) 推荐实战玩法：对于使用 Ruoyi-Vue-Plus 这种成熟脚手架的团队，工程师可以直接利用代码生成器，花 5 分钟生成一个带有真实基础增删改查（CRUD）功能的前端页面和后台接口。拿着这个“半成品”去给客户演示：“您看这几个搜索条件和表格字段够用吗？”，效率将产生质的飞跃。

🖥️ 【界面原型参考】将抽象需求具象化

图示：明确出左侧导航栏菜单树、中间的数据表格字段、右上角的 发布作业 按钮。让不懂技术的客户一眼看懂业务逻辑，签字确认无误后再动工敲业务代码。

教师工作页面👇

管理员系统管理页面👇

数据库表信息crud页面👇

2.3.4 现代敏捷开发利器：用户故事 (User Story)

在现代互联网公司（如采用 Scrum 敏捷开发的团队）中，不再长篇大论地写晦涩的需求文档，而是采用一种极简的格式——用户故事，它强制要求开发团队站在使用者的角度思考价值。

• 标准语法公式：作为一个 <角色>，我想要 <功能>，以便于 <商业价值>。

📌 【用户故事：项目 B 需求拆解案例】

• 常规写法（容易引发歧义）：系统需要增加导出成绩功能。
• 用户故事写法（精确锁定需求边界）：
  • 故事 1：作为一个 任课教师，我想要在成绩列表中一键单击 导出 Excel，以便于 我能快速将成绩导入教务处的期末大系统。
  • 故事 2：作为一个 学生，我想要在页面上看到带有红绿色块的 成绩及格状态提示，以便于 我一眼就能判断自己是否需要参加补考。

💡 【行业前沿延伸】大语言模型 (AI) 在需求阶段的双刃剑

场景： 某组同学在做毕设时，为了应付开题报告，直接让大语言模型（如 ChatGPT 或 Gemini）生成了一份长达万字的《教务系统需求文档》。

反思与指导： AI 极其擅长做“虚拟打字员”，能利用 Markdown 表格帮我们把繁杂的表单字段信息（如用户名、密码、角色ID等）梳理得井井有条。但 AI 极易产生“幻觉”，它很可能会为了让文档显得高大上，自动给你加上“基于人脸识别的课堂微表情监控”这种完全超出你个人 Vue/Java 开发能力、且极其烧钱的离谱功能。

结论： AI 可以作为头脑风暴和排版的辅助，但人类工程师必须牢牢把控系统的技术边界。如果你连自己交上去的文档里写了什么功能都不懂，期末答辩时一定会面临灾难。