5.5软件概要设计
概要设计，用于子系统或模块设计，也可用新增业务需求的跨子系统设计。概要设计在总体设计框架下，遵循总体设计思想，丰富子系统或模块设计，从而能够指导开发实现子系统或模块。
由于软件总体设计从宏观上架构软件，距离开发实现，还有许多需要细化之处。如果系统由多个子系统组成，每个子系统可以视为一个独立的应用软件或服务，此时概要设计不可省略；如果系统不大，重点模块也应需要做概要设计来细化。可以理解为概要设计粒度介于总体设计和详细设计之间。
另外，概要设计与代码实现的联系更紧密一些，如代码分层、核心的对象类及关系等。
责任人：开发项目组长。
执行人：高级程序员、子系统或模块开发人员。
关键行为：分析和概要设计。
- 分析：根据子系统或模块的功能规划，结合对软件需求进行分析，完整把握需求；
- 概要设计：在总体设计框架下，完成子系统或模块的概要设计。
输入：
- 软件需求规格书（SRS）；
- 数据字典（DD）；
- 用户故事集合；
- 其它需求资料；
- 软件总体设计文档。
输出：
- 软件概要设计文档；
- 子系统结构设计；
- 功能模块设计；
- 接口设计；
- 软件结构设计；
- 数据库设计。
职责要求：
- 概要设计；
- 沟通、协调、明确对接的上下游子系统/模块的接口和边界；
- 提请软件概要设计评审：
- 概要设计人员：主讲人，负责讲解和答复各种质询和疑问；
- 产品经理：评估产品需求在子系统或模块的部分是否被设计的系统所满足；包括后期的需求的满足性；非功能需求的支持情况；
- 项目经理：组织、协调，关注子系统与其它相关子系统的衔接；
- 开发项目经理及高级技术人员：关注技术方案的可行性、灵活性；非功能需求的支持情况；关注子系统与其关子系统的衔接；
- 开发技术人员：了解软件的设计思路，便于开发实现；如前后端分离，前端开发人员需评审涉及前端接口的合理性；
- 测试技术人员：了解软件的设计思路，以及其对测试的影响；
5.6软件详细设计
详细设计，能够在开发人员编码实现前，评审其设计思路，肯定是有帮助的。但是，详细设计是需要时间开销的，做为设计的末端，其数量规模是很大的；如果需求不明确，则这些投入就可能白费。
在敏捷开发模式，详细设计一般都不做。在实际操作中，发现有些核心功能还得需要做详细设计，有了总体设计文档，概要设计文档和软件需求规格书，并不能保证每个开发人员都能跟上设计人员的思路，结果实现的效果参差不齐，有的完全没有按照总体设计思路来。
因此，我认为，重要或核心功能开发，还是需要做详细设计。具体需要开发项目组长来把握。
责任人：开发项目组长。
执行人：软件需求开发人员。
关键行为：分析和详细设计。
输入：
- 软件需求规格书（SRS）；
- 数据字典（DD）；
- 用户故事；
- 其它需求资料；
- 软件总体设计文档；
- 软件概要设计文档。
输出：
- 详细设计文档；
- 接口设计：YApi或swagger；
- 单元测试设计：checklist
职责要求：
- 详细设计；
- 理解需求；
- 沟通、协调、明确对接的上下游模块的接口和边界；
- 提请软件详细设计评审：
- 开发人员：主讲人，负责讲解和答复各种质询和疑问；
- 开发项目组长：关注技术方案的可行性；
- 上下游相关开发人员：评审接口、业务流程及性能等技术可行性；
- 高级技术人员：如果功能比较复杂，参与评审；
- 其它人员，视情况需要
理顺软件开发各个环节-13（开发管理-概要设计和详细设计）
原文：https://www.cnblogs.com/alabo1999/p/12989728.html
