简介《软件工程概要设计总体设计说明书》是一份面向软件工程学习者、项目开发人员与课程设计者的规范文档模板用于解决概要设计阶段文档结构不清晰、章节要素缺失的问题。文档按国家标准框架组织涵盖编写目的、背景、术语定义与参考资料等引言内容并重点展开总体设计部分包括需求规定、运行环境、基本设计概念与处理流程、系统结构划分、功能需求与程序关系、人工处理过程及尚未解决的问题同时延伸至接口设计、运行设计与系统数据结构设计等章节配有目录层级与图表化说明思路。资源包共1个doc文件约40KB体积轻便便于直接套用或按项目实际修改。目前已有1574人学习下载适合需要撰写课程设计、毕业设计或企业项目概要设计说明书的读者参考可快速掌握各章节应写什么、如何组织减少文档返工。1. 概要设计说明书到底该写什么从一份被退回三次的文档说起如果你正在做软件工程课程设计或毕业设计大概率绕不开一份叫《概要设计总体设计说明书》的文档。我带过几届学生的项目评审也帮不少团队改过这份文档最常见的场景是代码写得挺顺文档憋了两天交上去导师批注只有一句——“这是需求规格说明书的复制粘贴”。问题出在哪概要设计处在需求与详细设计之间它的核心任务不是描述“用户要什么”而是回答“系统用什么结构去满足”。具体来说它要定下模块怎么划分、模块之间怎么调用、数据怎么流、接口长什么样、关键算法选什么策略。这份文档写扎实了详细设计才有地基编码阶段才不会各写各的。它适合正在做课程设计的学生、刚接手文档工作的初级工程师以及需要把架构决策落成文字的技术负责人。下面我按实际写文档的顺序把这份说明书拆开讲透。2. 概要设计与需求规格说明书的分界线模块划分从哪一步开始2.1 先搞清楚两份文档各管什么很多人写概要设计时翻车根源在于没分清它和《软件需求规格说明书》的职责边界。需求规格说明书回答的是“系统必须做什么”用用例图、用例规约、非功能需求列表来描述外部可见的行为。概要设计回答的是“系统打算怎么做”用模块结构图、接口定义、数据流图来描述内部结构。举个具体例子需求里写“用户能查询订单状态”这是需求概要设计里写“订单查询请求由 OrderController 接收调用 OrderService.query()OrderService 再通过 OrderDAO 访问数据库返回 OrderDTO”这才是设计。判断一段内容该放哪份文档有个简单办法如果这句话描述的是用户或外部系统能感知的行为放需求如果描述的是系统内部组件之间的协作放概要设计。按这个标准筛一遍你会发现需求文档里大段的功能描述都不该出现在概要设计里。2.2 模块划分的三种常见粒度与选择依据模块划分是概要设计的第一个硬骨头。常见做法有三种粒度粒度划分依据适用场景模块数量级粗粒度按子系统/层划分中小型项目、课程设计510 个中粒度按功能域划分业务系统、毕业设计1030 个细粒度按职责单一原则划分大型系统、微服务30 个以上课程设计和毕业设计一般选中粒度就够了。划分时遵循高内聚低耦合同一个模块内部的元素关联越紧密越好模块之间的依赖越少越好。实际操作中我一般先用功能分解法把系统拆成几个大块再检查每个块能不能用一句话说清职责。如果一句话说不清说明还得继续拆如果两个块之间的调用关系超过三条考虑是否该合并。2.3 用结构图把模块关系画出来模块划分完之后需要用结构图Structure Chart表达。结构图不是流程图它展示的是模块之间的调用关系和数据传递不展示执行顺序。画结构图时注意几个约定矩形框表示模块箭头表示调用方向带空心圆的短箭头表示传递的数据带实心圆的短箭头表示传递的控制信息。一个常见的错误是把结构图画成了流程图加了判断框和循环框。结构图里不应该出现这些判断和循环属于模块内部的逻辑是详细设计阶段的事。概要设计阶段只需要说清“谁调用谁、传什么数据”。提示如果导师要求用特定工具画图Visio、Draw.io、PlantUML 都可以。课程设计一般手绘或用 Draw.io 导出 PNG 插入文档即可不必追求工具的高级功能。3. 接口设计与数据设计概要设计说明书里最容易写空的两块3.1 接口定义该写到什么程度接口设计是概要设计里最容易被写空的部分。很多文档只写“本模块提供查询接口”这等于没写。概要设计阶段的接口定义至少要包含接口名称、输入参数名称、类型、含义、输出结果类型、含义、异常情况。不需要写到具体的方法签名和参数校验逻辑那是详细设计的事。我一般用表格来组织接口定义比纯文字清晰得多接口名称输入输出异常queryOrderuserId: String, orderId: StringOrderDTOOrderNotFoundcreateOrderuserId: String, items: ListorderId: StringInsufficientStockcancelOrderorderId: String, reason: StringbooleanOrderNotCancellable这张表放在概要设计里开发人员一看就知道模块之间怎么对接。到了详细设计阶段再补充每个参数的长度限制、格式要求、校验规则。3.2 数据设计数据库表该在概要设计里定吗这个问题争议比较大。我的经验是概要设计阶段应该定逻辑数据模型也就是有哪些实体、实体之间什么关系但不必定物理表结构。逻辑模型用 ER 图表达就够了实体属性可以只列关键字段。物理表结构、索引、分区策略留到详细设计阶段。原因很简单概要设计的核心是结构决策如果过早陷入字段类型和索引优化容易捡了芝麻丢了西瓜。而且实际项目中逻辑模型确定后物理设计往往要根据具体数据库特性调整提前定死反而限制后续优化空间。不过课程设计和毕业设计有个现实问题评审老师往往希望看到完整的数据库设计。这种情况下我建议在概要设计里放逻辑 ER 图加核心表的关键字段说明详细设计里再放完整的建表语句。3.3 数据流图怎么画才不被挑毛病数据流图DFD是概要设计的另一个常用工具。画 DFD 时最常见的毛病是层次混乱顶层图里出现了不该有的细节底层图里又缺少必要的数据存储。我的做法是严格分层——顶层图只画系统和外部实体的交互0 层图展开主要加工1 层图再展开子加工。每层只画该层该有的东西不越级。另一个常见问题是数据流命名不规范。数据流应该是一个名词或名词短语表示流动的数据内容比如“订单信息”“用户凭证”而不是“查询订单”这种动词短语。加工命名则相反应该是动词短语比如“验证用户身份”“生成订单记录”。4. 概要设计说明书的文档结构与评审要点4.1 一份能过评审的文档目录长什么样根据 GB/T 8567 的推荐结构和实际评审经验一份完整的概要设计说明书通常包含以下章节引言编写目的、背景、术语定义、参考资料总体设计需求概述、运行环境、设计原则、总体结构模块设计模块清单、各模块职责与接口数据设计逻辑数据模型、数据流图接口设计外部接口、内部接口运行设计运行模块组合、运行控制、运行时间出错处理设计出错信息、补救措施安全保密设计维护设计课程设计和毕业设计不必全部覆盖但第 2、3、4、5 章是核心不能省。第 6、7 章可以根据项目规模适当简化。第 8、9 章如果项目不涉及可以合并或省略。4.2 评审时被问最多的三个问题根据我参与评审的经验老师或技术负责人最常追问的三个问题是第一“你这个模块划分的依据是什么”——回答不能只说“按功能分的”要说出具体的划分原则比如“按业务领域划分每个模块对应一个独立的业务能力模块之间通过明确定义的接口通信”。第二“这个接口如果调用失败怎么处理”——概要设计阶段不需要给出完整的异常处理代码但要说清异常传递路径和兜底策略比如“DAO 层抛出异常后由 Service 层捕获并转换为业务异常Controller 层统一返回错误码”。第三“数据流图里这个数据存储为什么放在这里”——每个数据存储的位置都要有理由不能随便画。常见理由是“该数据需要被多个加工共享”或“该数据需要持久化”。4.3 用文档模板快速起步如果是从零开始写找一个靠谱的模板能省不少时间。我一般会准备一份 Markdown 格式的模板包含所有章节标题和填写说明写的时候直接往里填内容。模板里会预置好表格格式、图编号规则、术语表结构避免写到一半发现格式不统一。注意模板只是脚手架不要为了填满模板而写废话。评审看的是内容质量不是页数。我见过把需求文档整段复制过来凑页数的反而扣分。5. 避坑概要设计说明书写作中的五个高频翻车点5.1 把概要设计写成了详细设计现象文档里出现了具体的方法实现逻辑、循环条件、变量赋值语句。原因写的时候不自觉往下钻把“怎么做”写成了“具体怎么编码”。解决每写完一段就问自己“这是在说结构还是在说实现”如果是实现移到详细设计文档里。概要设计只定模块边界和接口不定内部逻辑。5.2 模块划分过细或过粗现象要么模块多到几十个每个只有一两个功能要么只有三四个大模块每个模块职责说不清。原因划分时没有统一标准凭感觉拆。解决先确定划分粒度参考 2.2 节的表格然后按职责单一原则检查每个模块。如果一个模块的职责描述超过两句话考虑拆分如果两个模块的职责高度重叠考虑合并。5.3 接口定义缺少异常说明现象接口表里只有正常输入输出没有异常情况。原因写的时候只考虑了正常流程。解决每个接口至少考虑三类异常——输入非法、资源不可用、权限不足。异常说明不需要写处理代码但要写清异常名称和触发条件。5.4 数据流图层次混乱现象顶层图里出现了数据库表底层图里出现了外部实体。原因画图时没有严格分层。解决画之前先确定分几层每层只画该层该有的元素。顶层图只有系统和外部实体0 层图展开主要加工数据存储从 0 层开始出现。5.5 文档与需求规格说明书脱节现象概要设计里出现的模块在需求文档里找不到对应的功能点或者需求里的功能在概要设计里没有对应的模块。原因两份文档分开写没有做交叉检查。解决写完概要设计后拿需求文档的功能列表逐条对照确保每个需求都有对应的模块承接每个模块都能追溯到至少一个需求。6. 从概要设计到详细设计的衔接技巧一份检查清单概要设计写完不是终点它要能直接指导详细设计和编码。我一般用一份检查清单来验证衔接质量检查项通过标准模块覆盖每个需求功能点都有对应模块接口完整每个模块的对外接口都有定义数据一致数据流图中的数据存储与 ER 图一致异常可追溯每个接口的异常都有上层处理策略粒度合适模块数量在合理范围内职责清晰这份清单过一遍基本能保证概要设计不会成为“写完就没人看”的文档。到了详细设计阶段开发人员拿着模块清单和接口表就能直接分工不需要再来回翻需求文档猜意图。最后说个我自己的习惯每次写完概要设计我会假装自己是第一次看这份文档的开发人员从第一个模块开始往下读看能不能顺畅地理解每个模块要做什么、怎么跟其他模块对接。如果读到某个地方卡住了说明那里没写清楚回去补。这个“自读测试”帮我省了很多评审时被追问的尴尬。希望帮到你。本文还有配套的精品资源点击获取