勤曦爱人
1、系统详细设计主要包括以下内容：
确定设计方针和方法，将系统分解为若干子系统，确定各子系统的目标、功能及其相互关系，再决定对子系统的管理体制和控制方式，还有对各子系统进行技术设计和评价，以及对全系统进行技术设计和评价等。
2、系统详细设计就是根据系统分析的结果，运用系统科学的思想和方法，设计出能最大限度满足所要求目标 (或目的) 的新系统的过程。不论多大的复杂系统，都离不开以下三个方面：
①首先要分解为若干子系统或要素，分解可从结构要素、功能要求、时间序列、空间配置等方面进行；
②然后将其特征和性能标准化，综合成最优子系统；
③最后将最优子系统进行总体设计，从而得到最优系统。
扩展资料
系统详细设计的注意事项
1、阶段开发原则
系统框架和数据结构全面设计，具体功能实现分阶段进行。
2、易用性原则
方便上网客户浏览和操作，最大限度地减轻后台管理人员的负担，做到部分业务的自动化处理。
3、业务完整性原则
对于业务进行中的特殊情况能够做出及时、正确的响应，保证业务数据的完整性。
4、业务规范化原则
在系统设计的同时，也为将来的业务流程制定了较为完善的规范，具有较强的实际操作性。
5、可扩展性原则
系统设计要考虑到业务未来发展的需要，要尽可能设计得简明，各个功能模块间的耦合度小，便于系统的扩展，当然如果存在旧有的数据库系统，则需要充分考虑兼容性。
参考资料：百度百科-系统设计
软件详细设计说明书
面向对象软件设计说明书模板
1 概述
1.1 系统简述
对系统要完成什么，所面向的用户以及系统运行的环境的简短描述，这部分主要来源于需求说明书的开始部分。
1.2 软件设计目标
这部分论述整个系统的设计目标，明确地说明哪些功能是系统决定实现而哪些时不准备实现的。同时，对于非功能性的需求例如性能、可用性等，亦需提及。需求规格说明书对于这部分的内容来说是很重要的参考，看看其中明确了的功能性以及非功能性的需求。
这部分必须说清楚设计的全貌如何，务必使读者看后知道将实现的系统有什么特点和功能。在随后的文档部分，将解释设计是怎么来实现这些的。
1.3 参考资料
列出本文档中所引用的参考资料。（至少要引用需求规格说明书）
1.4 修订版本记录
列出本文档修改的历史纪录。必须指明修改的内容、日期以及修改人。
2 术语表
对本文档中所使用的各种术语进行说明。如果一些术语在需求规格说明书中已经说明过了，此处不用再重复，可以指引读者参考需求说明。
3 用例
此处要求系统用用例图表述（UML），对每个用例（正常处理的情况）要有中文叙述。
4 设计概述
4.1 简述
这部分要求突出整个设计所采用的方法（是面向对象设计还是结构化设计）、系统的体系结构（例如客户/服务器结构）以及使用到的相应技术和工具（例如OMT、Rose）
4.2 系统结构设计
这部分要求提供高层系统结构的描述，使用方框图来显示主要的组件及组件间的交互。最好是把逻辑结构同物理结构分离，对前者进行描述。别忘了说明图中用到的俗语和符号。
4.2.1 顶层系统结构
4.2.2 子系统1结构
4.2.3 子系统2结构
4.3 系统界面
各种提供给用户的界面以及外部系统在此处要予以说明。如果在需求规格说明书中已经对用户界面有了叙述，此处不用再重复，可以指引读者参考需求说明。如果系统提供了对其它系统的接口，比如说从其它软件系统导入/导出数据，必须在此说明。
4.4 约束和假定
描述系统设计中最主要的约束，这些是由客户强制要求并在需求说明书写明的。说明系统是如何来适应这些约束的。
另外如果本系统跟其它外部系统交互或者依赖其它外部系统提供一些功能辅助，那么系统可能还受到其它的约束。这种情况下，要求清楚地描述与本系统有交互的软件类型（比如某某某数据库软件，某某某EMail软件）以及这样导致的约束（比如只允许纯文本的Email）。
实现的语言和平台也会对系统有约束，同样在此予以说明。
对于因选择具体的设计实现而导致对系统的约束，简要地描述你的想法思路，经过怎么样的权衡，为什么要采取这样的设计等等。
5 对象模型
5.1 系统对象模型
提供整个系统的对象模型，如果模型过大，按照可行的标准把它划分成小块，例如可以把客户端和服务器端的对象模型分开成两个图表述。
对象图应该包含什么呢？
在其中应该包含所有的系统对象。这些对象都是从理解需求后得到的。要明确哪些应该、哪些不应该被放进图中。
所有对象之间的关联必须被确定并且必须指明联系的基数（一对一、一对多还是多对多，0..1，*，1..*）。聚合和继承关系必须清楚地确定下来。每个图必须附有简单的说明。
可能经过多次反复之后才能得到系统的正确的对象模型。
6 对象描述
在这个部分叙述每个对象的细节，它的属性、它的方法。在这之前必须从逻辑上对对象进行组织。你可能需要用结构图把对象按子系统划分好。
为每个对象做一个条目。在系统对象模型中简要的描述它的用途、约束（如只能有一个实例），列出它的属性和方法。如果对象是存储在持久的数据容器中，标明它是持久对象，否则说明它是个临时对象（transient object）。
对每个对象的每个属性详细说明：名字、类型，如果属性不是很直观或者有约束（例如，每个对象的该属性必须有一个唯一的值或者值域是有限正整数等）。
对每个对象的每个方法详细说明：方法名，返回类型，返回值，参数，用途以及使用的算法的简要说明（如果不是特别简单的话）。如果对变量或者返回值由什么假定的话，Pre-conditions和Post-conditions必须在此说明。列出它或者被它调用的方法需要访问或者修改的属性。最后，提供可以验证实现方法的测试案例。
6.1 子系统1中的对象
6.1.1 对象：对象1
用途：
约束：
持久性：
6.1.1.1 属性描述：
1. 属性：属性1
类型：
描述：
约束：
2. 属性：属性2
6.1.1.2 方法描述：
1. 方法：方法1
返回类型：
参数：
返回值：
Pre-Condition：
Post-Condition：
读取/修改的属性：
调用的方法：
处理逻辑：
测试例：用什么参数调用该方法，期望的输出是什么……
7 动态模型
这部分的作用是描述系统如何响应各种事件。例如，可以建立系统的行为模型。一般使用顺序图和状态图。
确定不同的场景（Scenario）是第一步，不需要确定所有可能的场景，但是必须至少要覆盖典型的系统用例。不要自己去想当然地创造场景，通常的策略是描述那些客户可以感受得到的场景。
7.1 场景（Scenarios）
对每个场景做一则条目，包括以下内容：
场景名：给它一个可以望文生义的名字
场景描述：简要叙述场景是干什么的以及发生的动作的顺序。
顺序图：描述各种事件及事件发生的相对时间顺序。
7.1.1 场景：场景1
描述：
动作1
动作2
7.2 状态图
这部分的内容包括系统动态模型重要的部分的状态图。可能你想为每个对象画一个状态图，但事实上会导致太多不期望的细节信息，只需要确定系统中一些重要的对象并为之提供状态图即可。
7.2.1 状态图1：
8 非功能性需求
在这个部分，必须说明如何处理需求文档中指定的非功能性需求。尽可能客观地评估系统应付每一个非功能性的需求的能力程度。如果某些非功能性需求没有完全在设计的系统中实现，请务必在此说明。另外，你也需要对系统将来的进化作一个估计并描述本设计如何使系统能够适应这些可预见的变化。
9 辅助文档
提供能帮助理解设计的相应文档。
10 词汇索引
文章录入
软件工程里面概要设计和详细设计各自做到什么程度怎么界定啊？看了很多介绍，还是不满意呀。
概要设计主要阐述系统的目标、建设原则，系统的功能模块及数据库概要设计（有哪些表名），概要设计面向设计人员和用户，简单说，用户也能看得懂，不要求太细节，是对用户需求的技术响应，是二者沟通的桥梁。
详细设计则是在概要设计的基础上对系统的各个模块进一步细化，分析各个模块的子模块，甚至给出各子模块的算法；数据库设计方面则要求到具体每张表的字段。通常面向开发人员，应该是开发人员看了你的详细设计，就可以直接写代码。
做软件项目设计文档怎么写啊
按照以下格式填就好了，不过是我自己写的，有不好的地方大家互相学习修改一下~
详细设计文档规范
1.0概述
这部分提供对整个设计文档的概述。描述了所有数据，结构，接口和软件构件级别的设计。
1.1 目标和对象
描述软件对象的所有目标。
1.2 陈述范围
软件描述。主要输入，过程功能，输出的描述，不考虑详细细节。
1.3 软件内容
软件被置于商业或者产品线中，讨论相关的战略问题。目的是让读者能够对“宏图”有所了解。
1.4 主要系统参数
任何商务软件或者产品线都包含软件规定、设计、实现和测试的说明和规范。
2.0 数据设计
描述所有数据结构包括内部变量，全局变量和临时数据结构。
2.1 内部软件数据结构
描述软件内部的构件之间的数据传输的结构。
2.2 全局数据结构
描述主要部分的数据结构。
2.3 临时数据结构
为临时应用而生成的文件的描述。
2.4 数据库描述
作为应用程序的一部分，描述数据库结构。
3.0 结构化和构件级别设计
描述程序结构。
3.1 程序结构
详细描述应用程序所选定的程序结构。
3.1.1 结构图
图形化描述结构。
3.1.2 选择性
讨论其它可供考虑的结构。选定3.1.1中结构类型的原因。
3.2 构件描述
详细描述结构中的每个软件构件。
3.2.1 构件过程叙述(PSPEC)
描述构件的过程。
3.2.2 构件接口描述
详细描述构件的输入和输出。
3.2.3 构件执行细节
每个构件的详细演算描述。
3.2.3.1 接口描述
3.2.3.2 演算模型(e.g., PDL)
3.2.3.3 规范/限制
]3.2.3.4 本地数据结构
3.2.3.5 在3.2.3.6设计中包含的执行结果
3.3 软件接口描述
软件对外界的接口描述
3.3.1机器对外接口
与其他机器或者设备的接口描述。
3.3.2系统对外接口
对其它系统、产品和网络的接口描述。
3.3.3与人的接口
概述软件与任何人的界面。
4.0 用户界面设计
描述软件的用户界面设计。
4.1 描述用户界面
详细描述用户界面，包括屏幕显示图标、图片或者类型。
4.1.1 屏幕图片
从用户角度描述界面。
4.1.2 对象和操作
所有屏幕对象和操作的定义。
4.2 界面设计规范
用户界面的设计和实现的规范和标准。
4.3 可见构件
实现的GUI可见构件说明。
4.4 UIDS描述
用户界面开发系统描述。
5.0约束、限制和系统参数
会影响软件的规格说明、设计和实现的特殊事件。
6.0测试标准
测试策略和预备测试用例描述。
6.1 测试的类别
规定实施测试的类别，包括尽量详细的描述。这里是针对黑盒测试现象的描述。
6.2期待软件反馈
测试期待的结果描述。
6.3执行界线
特殊执行需要的说明。
6.4 重要构件确认
决定性构件或者需要特殊注意的构件的测试确认。
7.0附录
设计说明的补充信息。
7.1系统可跟踪矩阵
一个定期回归系统规格跟踪软件需求的矩阵。
7.2 产品战略
如果规格说明书是为一个产品设计的，描述相关的产品战略。
7.3 使用分析算法
描述所有分析活动所使用到的分析算法。
7.4 补充信息 (如果有需要特别说明的)
软件设计工程师主要是做什么的
软件设计师能根据软件开发项目管理和软件工程的要求，按照系统总体设计规格说明书进行软件设计，编写程序设计规格说明书等相应的文档；组织和指导程序员编写、调试程序，并对软件进行优化和集成测试，开发出符合系统总体设计要求的高质量软件；具有工程师的实际工作能力和业务水平。
工作内容：
软件设计师的工作，受到系统构架师的影响。当系统架构师决定了整个系统架构后，软件设计师会试着实作一个系统原型。
系统原型的目的，在验证系统架构师提出的架构。当架构过于复杂，或开发成本过高时，软件设计师必需要求系统架构师，修改提出的架构，因为在实务上，因为成本、技术等关系，是无法在经济的状况下达成。
软件设计师，必需对软件技术十分专长，也必需对客户的需求有一定程度的了解。在系统原型中，软件设计师会实作多个程式范型(Program Pattern)，每个程式范型，对应到一种客户需求的程式类型。
系统原型开发成功后，后续的团队，就可以使用完成的程式范型，快速地将客户的需求，转化为系统程式。
软件设计师日常工作：
“软件设计师”的概念，它与电子、机械、建筑行业的设计师有着同样的职责，可以只输出一种经过严格约束，并有着明显业务领域特色的设计说明与流程，而交给别人去实现，达到了很高的软件生产效率。
大多数企业只是对“系统分析员”与“软件工程师”做了明显的界定，“系统分析员”的职责在不同的企业区别较大，其工作范围涉及需求分析、功能设计、软件结构设计、接口设计等内容，有相当部分的“系统分析员”要承担一定程度的系统设计工作，但他们一般不参与编程与模块详细设计的工作；而绝大多数软件工程师则同时承担模块详细设计与编程的工作。
参考资料：软件设计师
软件详细设计的工具什么?简述几种常见的详细设计工具
（1）程序流程图。程序流程图又称为程序框图，是使用最广泛然而也是用得最混乱的一种描述程序逻辑结构的工具。它用方框表示一个处理步骤，菱形表示一个逻辑条件，箭头表示控制流向。其优点是：结构清晰，易于理解，易于修改。缺点是：只能描述执行过程而不能描述有关的数据。
（2）盒图。盒图是一种强制使用结构化构造的图示工具，也称为方框图。其具有以下特点：功能域明确、不可能任意转移控制、很容易确定局部和全局数据的作用域、很容易表示嵌套关系及模板的层次关系。
（3）PAD图。PAD是一种改进的图形描述方式，可以用来取代程序流程图，比程序流程图更直观，结构更清晰。最大的优点是能够反映和描述自顶向下的历史和过程。PAD提供了5种基本控制结构的图示，并允许递归使用。
PAD的特点有：使用PAD符号设计出的程序代码是结构化程序代码；PAD所描绘的程序结构十分清晰；用PAD图表现程序的逻辑易读、易懂和易记；容易将PAD图转换成高级语言源程序自动完成；即可以表示逻辑，也可用来描绘数据结构；支持自顶向下方法的使用。
（4）PDL。PDL也可称为伪码或结构化语言，它用于描述模块内部的具体算法，以便开发人员之间比较精确地进行交流。语法是开放式的，其外层语法是确定的，而内层语法则不确定。外层语法描述控制结构，它用类似于一般编程语言控制结构的关键字表示，所以是确定的。内层语法描述具体操作，考虑到不同软件系统的实际操作种类繁多，内层语法因而不确定，它可以按系统的具体情况和不同的设计层次灵活选用，实际上任意英语语句都可用来描述所需的具体操作。用它来描述详细设计，工作量比画图小，又比较容易转换为真正的代码。
PDL的优点：可以作为注释直接插在源程序中；可以使用普通的文本编辑工具或文字处理工具产生和管理；已经有自动处理程序存在，而且可以自动由PDL生成程序代码。
PDL的不足：不如图形工具形象直观，描述复杂的条件组合与动作间对应关系时，不如判定树清晰简单。
转载请注明出处51数据库 » 软件详细设计评审报告 系统详细设计包括哪些内容
