# 专题 10-12：系统规划、分析与设计

# 1. 三个阶段的定位

1
2
3
4

flowchart LR
    A[系统规划<br/>是否值得做] --> B[系统分析<br/>系统要做什么]
    B --> C[系统设计<br/>系统怎么做]
    C --> D[系统实现与测试]

# 2. 系统规划

系统规划是软件工程过程的起始阶段，用来定义项目范围、进度、预算和团队。它的关键任务是用较低成本判断项目是否值得继续。

# 核心目标

• 明确业务问题、机会或上级指示。
• 划定系统边界，避免范围蔓延。
• 通过可行性分析回答 “是否值得做”。
• 制定项目计划、预算、进度和团队安排。
• 向指导委员会汇报并获得正式授权。

# 项目启动的三类理由

# 3. 系统规划五大任务

1
2
3
4
5

flowchart LR
    A[列出触发项目的问题] --> B[协商初步范围]
    B --> C[评估项目价值]
    C --> D[计划进度、预算和成员]
    D --> E[汇报项目计划]

# 甘特图与 WBS

• WBS：把项目分解成可管理的工作包。
• 甘特图：用条状图表示任务、时间跨度和进度。
• PERT/CPM：分析任务依赖和关键路径。

# 4. 可行性分析

可行性分析是系统规划阶段的核心决策点，通常形成《可行性研究报告》。

决策结果通常有三种：

• 全部通过：立项。
• 有条件通过：调整范围、资源或计划后继续。
• 否决：终止或重新规划。

# 5. 项目成功与失败因素

常见失败原因：

• 系统需求不完整或频繁变化。
• 用户参与不足。
• 缺少管理层支持。
• 计划不充分，目标不清楚。
• 缺少必要资源。

成功关键因素：

• 清晰的需求定义。
• 大量且有效的用户参与。
• 上层管理支持。
• 完整详细的项目计划。
• 符合实际的进度和里程碑。

# 6. 系统分析

系统分析是软件生命周期第二阶段，核心任务是理解业务需求并转化为详细的系统需求规格。它承接系统规划，为系统设计提供需求基线。

# 系统需求分类

# 好需求的准则

• 一致：不相互冲突。
• 完整：覆盖所有必要输入、输出和响应。
• 可行：在资源和约束下能实现。
• 需要：确实支持系统目标。
• 正确：准确表达用户真实需求。
• 可追踪：能映射到设计、代码和测试。
• 可验证：能通过测试或评审证明是否满足。

# 7. 需求获取过程

需求获取不是一次性访谈，而是结构化过程。

1
2
3
4

flowchart LR
    A[发现和分析问题] --> B[获取需求]
    B --> C[归档和分析需求]
    C --> D[需求管理]

# 阶段一：发现和分析问题

核心是区分表面症状和根本问题，明确范围、目标和利益相关者。

输出：

• 问题陈述草案。
• 利益相关者清单。
• 初步系统改进目标。

# 阶段二：获取需求

系统分析员通常需要收集三类信息：

# 阶段三：归档和分析需求

常用工具：

• 用例：描述参与者与系统交互。
• 决策表：描述复杂业务规则。
• 需求表：结构化管理需求属性。
• SRS：正式记录功能需求、非功能需求、接口、约束。

常见问题：

• 遗漏、矛盾、不可行、重叠、二义性。

# 阶段四：需求管理

需求管理用于控制需求变化。项目中 50% 以上需求在上线前发生变化并不罕见。

重点：

• 建立正式变更流程。
• 每项变更评估影响并获得批准。
• 维护需求基线。
• 建立需求追溯矩阵。

# 8. 七种调查研究技术

推荐策略：

1. 先看现有文档、表格、报告。
2. 合适时观察现有系统。
3. 用问卷澄清大范围问题。
4. 再做面谈或 JRP。
5. 对难以理解的功能构造获取原型。
6. 对不确定信息追查到底。

# 9. 系统分析阶段的 UML 使用

# 10. 系统设计

系统设计基于系统分析输出的 SRS，制定技术解决方案。它把业务语言转化为开发人员可实现的架构、组件、接口、数据模型和部署方案。

# 系统分析与系统设计对比

# 11. 系统设计的两级活动

# 架构设计 / 概要设计

主要任务：

• 确定分层架构、微服务、事件驱动等总体结构。
• 选择编程语言、框架、中间件和数据库。
• 划分模块、包、子系统和构件。
• 定义构件提供接口和需求接口。
• 规划部署节点和网络通信。
• 落实安全、性能、可扩展性等非功能需求。

常见架构模式：

# 详细设计

主要任务：

• 类设计：属性、方法、类型、可见性。
• 交互设计：用序列图描述关键用例实现。
• 状态设计：为复杂对象设计状态机。
• 数据库物理设计：表结构、字段、索引、约束。
• 界面设计：导航、布局、校验规则。
• 算法设计：复杂逻辑用活动图或伪代码表达。

# 12. 设计原则与常见反模式

# SOLID 原则

# 高内聚、低耦合

• 内聚：模块内部元素相关程度，越高越好。
• 耦合：模块之间相互依赖程度，越低越好。

# 常见反模式

• 上帝类：一个类承担过多职责。
• 瑞士军刀接口：接口过大，客户被迫依赖不需要的方法。
• 循环依赖：模块互相依赖，难以维护和测试。
• 功能依恋：一个类过度使用另一个类的数据。
• 过度设计：为不存在的未来需求设计复杂结构。

# 13. 设计阶段工作流与输出

1
2
3
4
5
6

flowchart LR
    A[审查需求模型] --> B[确定设计策略]
    B --> C[架构设计]
    C --> D[详细设计]
    D --> E[应用设计原则与模式]
    E --> F[评审与基线化]

# 分析到设计的转化

# 设计阶段输出物

• 系统设计说明书（SDD）。
• 系统架构图：包图、构件图。
• 设计类图。
• 数据库设计文档：ER 图、表结构。
• 接口协议文档：API 定义。
• 非功能需求实现策略。
• 详细设计文档：序列图、状态图、算法活动图、界面原型。
• 部署架构图。
• 设计评审记录。

# 14. 本专题考点提炼

1. 系统规划回答 “是否值得做”，系统分析回答 “做什么”，系统设计回答 “怎么做”。
2. 系统规划五大任务：列问题、协商范围、评估价值、制定计划、汇报计划。
3. 可行性分析至少包括技术、经济、操作、法律 / 合规、进度、资源等维度。
4. 功能需求描述系统做什么，非功能需求描述质量属性和约束。
5. 好需求应一致、完整、可行、必要、正确、可追踪、可验证。
6. 七种调查研究技术要组合使用，不要只靠面谈或个人假设。
7. 系统设计分为架构设计和详细设计。
8. 分析模型偏业务，设计模型偏技术实现。
9. 高内聚、低耦合和 SOLID 是设计阶段的核心质量原则。

# 15. 快速自测

• 系统规划阶段为什么通常不大量引入普通用户？
• 项目范围陈述为什么重要？
• 可行性分析中经济可行性和操作可行性分别关注什么？
• 面谈、问卷、JRP、观察分别适合什么场景？
• SRS 应解决哪些问题？
• 架构设计和详细设计的区别是什么？
• 为什么设计类图不能简单照搬分析类图？