奸情哥哥
文档的软件设计说明
软件设计阶段结束后要交付软件设计说明书。
它的前半部分在概要设计后完成，后半部分在详细设计后写出。
设计说明书用于双重目的：对于编程和测试，它提供指南；软件交付使用后，为维护人员提供帮助。
软件设计说明书的框架和内容如下：(1)概述。
描述设计工作总的范围，包括系统目标、功能、接口等。
(2)系统结构。
用软件结构图说明本系统的模块划分，扼要说明每个模块的功能，按层次给出各模块之间的控制关系。
(3)数据结构及数据库设计。
对整个系统使用的数据结构及数据库进行设计，包括概念结构设计、逻辑结构设计和物理设计。
用相应的图形和表格把设计结果描述出来。
(4)接口设计。
设计人机界面，说明向用户提供的命令以及系统的返回信息；设计外部接口，说明本系统与外界的所有接口信息，包括软件与硬件之间的接口、本系统与支持软件之间的接口关系。
(5)模块设计。
按模块功能详细描述每个模块的流程及数据结构。
如何 写 详细设计文档
在大多数软件项目中，要末不作详细设计，要么开发完成后再补详细设计文档，质量也不容乐观，文档与系统往往不能同步，使详细设计文档完全流于形式，对工作没有起到实际的帮助。
那到底应不应该写详细设计文档呢，怎么使详细设计文档起到他应有的作用呢，下面就让我们来认识一下详细设计及写详细设计文档的好处和问题。
· 什么是详细设计详细设计是相对概要设计而言的，是瀑布开发流程的一个重要环节，在概要设计的高层设计的基础上，从逻辑上实现了每一模块的功能，是编码阶段的主要参考资料，是从高层到低层、逐步精化思想的具体实现。
详细设计文档的内容包括各个模块的算法设计， 接口设计， 数据结构设计，交互设计等。
必须写清楚各个模块/接口/公共对象的定义，列明各个模块程序的各种执行条件与期望的运行效果，还要正确处理各种可能的异常。
· 为什么要作详细设计在开发过程中，由需求及设计不正确、不完整所导致的问题是项目进度拖延、失败的一个主要因素，而软件系统的一个重要特性就是需求和设计的不断构建和改进，在写详细设计文档过程中， 详细设计实际上是对系统的一次逻辑构建，可以有效验证需求的完整性及正确性。
如果不写详细设计文档，一般就从概设直接进入编码阶段，这时开发人员所能参考的资料就是需求规格说明书及页面原型、数据库设计等，不能直接进行开发，需要进行信息的沟通，把页面原型不能体现的设计讲清楚，这样既容易遗忘，也容易发生问题，详细设计文档可以作为需求人员、总体设计人员与开发人员的沟通工具，把静态页面无法体现的设计体现出来，包含整体设计对模块设计的规范，体现对设计上的一些决策，例如选用的算法，对一些关键问题的设计考虑等等，使开发人员能快速进入开发，提高沟通效率，减少沟通问题。
对于系统功能的调整，后期的维护，详设文档提供了模块设计上的考虑、决策，包括模块与整体设计的关系、模块所引用的数据库设计、重要操作的处理流程、重要的业务规则实现设计等等信息，提供了对模块设计的概述性信息，阐明了模块设计上的决策，配合代码注释，可以相对轻松读懂原有设计。
· 存在的问题要由专门的人写，是比较麻烦的，也是很需要时间的，会对进度造成压力，也容易形成工作瓶颈，使设计人员负担过重，而开发人员无事可作。
对于现在一般的以数据库为中心的管理系统而言，这个工作始终是要作的，区别只不过是不是形成专门文档，形成文档可能会多花一两周时间，但相对于规避的风险和问题来说，也是值得的，另外由于现在高级语言的流行，所以更详细的设计应该直接体现在代码的设计上，而文档则只体现设计上的一些决策，协调整体设计与模块设计的关系，把页面原型所不能体现的设计情况文档化，所以所花费的时间是有限的。
设计内容容易过细，但设计阶段是不能考虑特别清楚地，时间也不允许。
对于这个问题，一个对策是上边所提到的，文档只体现设计上的决策，页面原型所不能反映的信息，详细设计只体现总体设计对模块设计的一些考虑，例如对功能的数据库设计等等，而具体的实现实现，则到代码中再去实现，相关的设计也仅体现在代码中。
需求、设计需要不断的被更新、构建，则设计文档需要不断的重新调整，文档的维护需要跟上，否则文档和系统的同步就很难得到保障了，且造成多余的工作量。
文档的内容易流于形势，质量糟糕，不能成为开发人员的参考手册，一是要建立起相关制度，如有修改，先改文档，后作开发，从工作流程上切实保障文档与系统的同步，二是要规范文档质量，对文档该写什么，不该写什么，标准是什么，粒度是什么，语法应该如何组织，有明确的标准和考虑，同时，建立审计文档评审、审核制度，充分保障系统的使用。
· 应该如何写详细设计文档下面讨论如何写出一个符合要求、实用的详细设计文档。
首先是文档的内容，根据项目和团队的不同，详细设计文档的内容也有所不同，一般说来，粒度不宜过细，不能代替开发人员的设计和思考，但要把有关设计的决策考虑进去，包括与其他模块、整体设计的关系、操作的处理流程，对业务规则的设计考虑等，有一个标准为，凡是页面原型、需求规格说明书所不能反映的设计决策，而开发人员又需要了解的，都要写入文档。
其次是文档所面向的读者，主要为模块开发人员、后期维护人员，模块开发人员通过详细设计文档和页面原型来了解所开发的功能，后期维护人员通过实际系统、模块代码、详细设计文档来了解一个功能。
再有就是谁来写文档，因为文档主要考虑的是设计上的决策，所以写文档的人应该为负责、参加设计的技术经理、资深程序员，根据团队情况和项目规模、复杂度的不同，也有所不同。
还需要保证文档的可读性、准确性、一致性，要建立严格的文档模板及标准，保证文档的可读性及准确性，同时建立审核及设计评审制度，来保障设计及文档的质量，另外在工作流程中要强调，要先设计、先写文档，再进行开发。
企业网站数据库设计文档怎么写啊？哪位高手教教我啊？
按照以下格式填就好了，不过是我自己写的，有不好的地方大家互相学习修改一下~ 详细设计文档规范 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 补充信息 （如果有需要特别说明的）
做软件项目设计文档怎么写啊
展开全部 按照以下格式填就好了，不过是我自己写的，有不好的地方大家互相学习修改一下~ 详细设计文档规范 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 补充信息 （如果有需要特别说明的）
软件详细设计说明书
展开全部 面向对象软件设计说明书模板 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） 对每个场景做一则条目，包括以下内容： 场景名：给它一个可以望文生义的名字 场景描述：简要叙述场景是干什么的以及发生的动作的顺序。
顺序图：描述各种事件及事...
利用数据库,设计软件
展开全部 软件文档中概要设计也称“总体设计”，是开发人员在明确用户需求（要什么）后对系统的一个总体考虑（明确系统目标、设计原则，初步考虑数据库设计和功能设计），国家关于这方面有相关标准（概要设计说明书（GB8567-88））。
在具体实践中可以按下列提纲撰写内容：1.引言1.1编写目的[说明编写这份概要设计说明书的目的，指出预期的读者。
]1.2背景a.[待开发软件系统的名称；]b.[列出本项目的任务提出者、开发者、用户。
]1.3定义[列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
]1.4参考资料 [列出有关的参考资料。
]2.总体设计2.1需求规定 [说明对本系统的主要的输入输出项目、处理的功能性能要求。
包括] 2.1.1系统功能 2.1.2系统性能 2.1.2.1精度 2.1.2.2时间特性要求 2.1.2.3可靠性 2.1.2.4灵活性 2.1.3输入输出要求 2.1.4数据管理能力要求 2.1.5故障处理要求 2.1.6其他专门要求2.2运行环境 [简要地说明对本系统的运行环境的规定。
] 2.2.1设备 [列出运行该软件所需要的硬设备。
说明其中的新型设备及其专门功能。
] 2.2.2支持软件 [列出支持软件，包括要用到的操作系统、编译（或汇编）程序、测试支持软件等。
] 2.2.3接口 [说明该系统同其他系统之间的接口、数据通信协议等] 2.2.4控制 [说明控制该系统的运行的方法和控制信号，并说明这些控制信号的来源。
]2.3基本设计概念和处理流程 [说明本系统的基本设计概念和处理流程，尽量使用图表的形式。
]2.4结构[给出系统结构总体框图（包括软件、硬件结构框图），说明本系统的各模块的划分，扼要说明每个系统模块的标识符和功能，分层次地给出各模块之间的控制与被控制关系。
]2.5功能需求与系统模块的关系 [本条用一张矩阵图说明各项功能需求的实现同各模块的分配关系。
]2.6人工处理过程 [说明在本系统的工作过程中不得不包含的人工处理过程。
]2.7尚未解决的问题 [说明在概要设计过程中尚未解决而设计者认为在系统完成之前必须解决的各个问题。
]3.接口设计3.1用户接口 [说明将向用户提供的命令和它们的语法结构，以及相应的回答信息。
] [说明提供给用户操作的硬件控制面板的定义。
]3.2外部接口 [说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持系统之间的接口关系。
]3.3内部接口 [说明本系统之内的各个系统元素之间的接口的安排。
]4.运行设计4.1运行模块组合 [说明对系统施加不同的外界运行控制时所引起的各种不同的运行模块组合，说明每种运行所历经的内部模块的支持软件。
]4.2运行控制 [说明每一种外界的运行控制的方式方法和操作步骤。
]4.3运行时间 [说明每种运行模块组合将占用各种资源的时间。
]5.系统数据结构设计 [不涉及软件设计可不包含]5.1逻辑结构设计要点 [给出本系统内软件所使用的每个数据结构的名称、标识符以及它们之中每个数据项、记录、文卷和系的标识、定义、长度及它们之间的层次的或表格的相互关系。
]5.2物理结构设计要点 [给出本系统内软件所使用的每个数据结构中的每个数据项的存储要求，访问方法、存取单位、存取的物理关系、设计考虑和保密条件。
]5.3数据结构与程序的关系 [说明各个数据结构与访问这些数据结构的各个程序之间的对应关系。
]6.系统出错处理设计6.1出错信息 [用一览表的方式说明每种可能的出错或故障情况出现时，系统输出信息的形式、含意及处理方法。
]6.2补救措施 [说明故障出现后可能采取的变通措施。
]6.3系统维护设计 [说明为了系统维护的方便而在程序内部设计中作出的安排，包括在程序中专门安排用于系统的检查与维护的检测点和专用模块。
]
简述数据库应用系统的设计步骤
展开全部数据库应用系统的开发是一项软件工程。
一般可分为以下几个阶段： 1.规划 2.需求分析 3.概念模型设计 4. 逻辑设计 5.物理设计 6.程序编制及调试 7.运行及维护。
这些阶段的划分目前尚无统一的标准，各阶段间相互联接，而且常常需要回溯修正。
在数据库应用系统的开发过程中，每个阶段的工作成果就是写出相应的文档。
每个阶段都是在上一阶段工作成果的基础上继续进行，整个开发工程是有依据、有组织、有计划、有条不紊地展开工作。
1.规划 规划的主要任务就是作必要性及可行性分析。
在收集整理有关资料的基础上，要确定将建立的数据库应用系统与周边的关系，要对应用系统定位，其规模的大小、所处的地位、应起的作用均须作全面的分析和论证。
明确应用系统的基本功能，划分数据库支持的范围。
分析数据来源、数据采集的方式和范围，研究数据结构的特点，估算数据量的大小，确立数据处理的基本要求和业务的规范标准。
规划人力资源调配。
对参与研制和以后维护系统运作的管理人员、技术人员的技术业务水平提出要求，对最终用户、操作员的素质作出评估。
拟定设备配置方案。
论证计算机、网络和其他设备在时间、空间两方面的处理能力，要有足够的内外存容量，系统的响应速度、网络传输和输入输出能力应满足应用需求并留有余量。
要选择合适的os,dbms和其它软件。
设备配置方案要在使用要求、系统性能、购置成本和维护代价各方面综合权衡。
对系统的开发、运行、维护的成本作出估算。
预测系统效益的期望值。
拟定开发进度计划，还要对现行工作模式如何向新系统过渡作出具体安排。
规划阶段的工作成果是写出详尽的可行性分析报告和数据库应用系统规划书。
内容应包括：系统的定位及其功能、数据资源及数据处理能力、人力资源调配、设备配置方案、开发成本估算、开发进度计划等。
可行性分析报告和数据库应用系统规划书经审定立项后，成为后续开发工作的总纲。
数据库应用系统的开发是一项软件工程，本文介绍了数据库应用系统的开发步骤…… 2.需求分析 需求分析大致可分成三步来完成。
（1） 需求信息的收集， 需求信息的收集一般以机构设置和业务活动为主干线，从高层中层到低层逐步展开 （2） 需求信息的分析整理， 对收集到的信息要做分析整理工作。
数据流图（dfd, data flow diagram）是业务流程及业务中数据联系的形式描述。
图4.1是一个简单的dfd 示例。
数据字典（dd, data dictionary）详细描述系统中的全部数据。
数据字典包含以下几个部分。
· 数据项：是数据的原子单位。
· 数据组项：由若干数据项组成。
· 数据流：表示某一数据加工过程的输入/输出数据。
· 数据存储：是处理过程中要存取的数据。
· 数据加工过程 数据加工过程的描述包括：数据加工过程名、说明、输入、输出、加工处理工作摘要、加工处理频度、加工处理的数据量、响应时间要求等。
数据流图既是需求分析的工具，也是需求分析的成果之一。
数据字典是进行数据收集和数据分析的主要成果。
（3） 需求信息的评审. 开发过程中的每一个阶段都要经过评审，确认任务是否全部完成，避免或纠正工作中出现的错误和疏漏。
聘请项目外的专家参与评审，可保证评审的质量和客观性。
评审可能导致开发过程回溯，甚至会反复多次。
但是，一定要使全部的预期目标都达到才能让需求分析阶段的工作暂告一个段落. 需求分析阶段的工作成果是写出一份既切合实际又具有预见的需求说明书，并且附以一整套详尽的数据流图和数据字典。
3.概念模型设计 概念模型不依赖于具体的计算机系统，他是纯粹反映信息需求的概念结构。
建模是在需求分析结果的基础上展开，常常要对数据进行抽象处理。
常用的数据抽象方法是‘聚集’和‘概括’。
er方法是设计概念模型时常用的方法。
用设计好的er图再附以相应的说明书可作为阶段成果 概念模型设计可分三步完成。
（1） 设计局部概念模型 ① 确定局部概念模型的范围 ② 定义实体 ③ 定义联系 ④ 确定属性 ⑤ 逐一画出所有的局部er图，并附以相应的说明文件数据库应用系统的开发是一项软件工程，本文介绍了数据库应用系统的开发步骤…… （2） 设计全局概念模型 建立全局er图的步骤如下： ① 确定公共实体类型 ② 合并局部er图 ③ 消除不一致因素 ④ 优化全局er图 ⑤ 画出全局er图，并附以相应的说明文件。
（3） 概念模型的评审 概念模型的评审分两部分进行 第一部分是用户评审。
第二部分是开发人员评审。
4.逻辑设计 逻辑设计阶段的主要目标是把概念模型转换为具体计算机上dbms所支持的结构数据模型。
逻辑设计的输入要素包括：概念模式、用户需求、约束条件、选用的dbms的特性。
逻辑设计的输出信息包括：dbms可处理的模式和子模式、应用程序设计指南、物理设计指南。
（1） 设计模式与子模式 关系数据库的模式设计可分四步完成。
① 建立初始关系模式 ② 规范化处理 ③ 模式评价 ④ 修正模式 经过多次的模式评价和模式修正，确定最终的模式和子模式。
写出逻辑数据库结构说明书。
数据库应用系统的开发是一项软件工程，本文介绍了数据库应用系统的开发步骤…… （2） 编写...
软件工程实例 报告 文档 程序 都有
1 引言。
1编写目的： 可行性研究的目的是为了对问题进行研究，以最小的代价在最短的时间内确定问题是否可解 经过对此项目进行详细调查研究，初拟系统实现报告，对软件开发中将要面临的问题及其解决方案进行初步设计及合理安排。
明确开发风险及其所带来的经济效益。
本报告经审核后，交软件经理审查。
1.2 项目背景： 开发软件名称：超市进销存系统。
项目任务提出者：老师。
项目开发者：shu408157847。
用户：超市。
实现软件单位：学校 项目与其他软件，系统的关系： 本项目采用客户机/服务器原理，客户端的程序是建立在Windows NT 系统上以Microsoft Visual C++为开发软件的应用程序，服务器端采用Linux 为操作系统的工作站，是采用Oracle 8的为开发软件的数据库服务程序。
1.3 定义： [专门术语]： [缩写词]： 1.4 参考资料： 《软件工程导论》，张海藩，清华大学出版社。
《实用软件工程》，郑人杰等，清华大学出版社。
2.可行性研究的前提 2.1要求 主要功能： 性能要求： 对服务器上的数据必须进行及时正确的刷新。
输出要求：数据完整，详实。
输出要求：简捷，快速，实时。
安全与保密要求：权限不同 完成期限：预计六个月，即截止2007年12月8日。
2.2目标： 系统实现后，大大提高旅游局的机票预定服务效率超市的管理水平。
降低误差，减少开销 2.3条件，假定和限制 建议软件寿命：5年。
经费来源：。
硬件条件：服务器sun工作站，终端为pc机。
运行环境：Linux 数据库：Oracle8 投入运行最迟时间：2000/04/04 2.4可行性研究方法 2.5决定可行性的主要因素 1 经济可行性 成本/效益分析结果，短期-长期利益分析。
技术可行，现有技术可完全承担开发任务。
操作可行，软件能被原有工作人员快速接受。
3.技术可行性分析 3.1系统简要描述 3.2处理流程和数据流程 3.3环境可行性 3.4 人员可行性：操作宜学 3.5 效益分析 投资回收周期 2.3年 4.5敏感性分析 设计系统周期为五年， 估计最长可达10年 处理速度：一般查询速度<4秒 关键数据查询速度： <2秒 5。
法律因素 6。
其他可供选择的方案 7.结论意见 由于投资效益比远大于100%， 技术、经济、操作都有可行性，可以进行开发. 以上为包含步骤，供你参考！！
