当前位置:文档之家› 概要设计与详细设计的区别

概要设计与详细设计的区别

概要设计与详细设计的区别
概要设计与详细设计的区别

概要设计与详细设计的区别

概要设计就是设计软件的结构,包括组成模块,模块的层次结构,模块的调用关系,每个模块的功能等等。同时,还要设计该项目的应用系统的总体数据结构和数据库结构,即应用系统要存储什么数据,这些数据是什么样的结构,它们之间有什么关系。

详细设计阶段就是为每个模块完成的功能进行具体的描述,要把功能描述转变为精确的、结构化的过程描述。

概要设计阶段通常得到软件结构图

详细设计阶段常用的描述方式有:流程图、N-S图、PAD图、伪代码等

概要设计和详细设计

在软件设计中,大家经常问到的一个问题是:概要设计应该怎样一个概要法,详细设计应该怎样一个详细法?

这个问题在公司内部经常有人问。现在陈述一下。

我们公司的研发流程是瀑布型的,这个模型中的分析、设计阶段是基于经典的结构化方法。

结构化设计方法的基本思路是:按照问题域,将软件逐级细化,分解为不必再分解的的模块,每个模块完成一定的功能,为一个或多个父模块服务(即接受调用),也接受一个或多个子模块的服务(即调用子模块)。模块的概念,和编程语言中的子程序或函数是对应的。

这样一来,设计可以明显地划分成两个阶段:

概要(结构)设计阶段:把软件按照一定的原则分解为模块层次,赋予每个模块一定的任务,并确定模块间调用关系和接口。

详细设计阶段:依据概要设计阶段的分解,设计每个模块内的算法、流程等。

概要设计阶段:

在这个阶段,设计者会大致考虑并照顾模块的内部实现,但不过多纠缠于此。主要集中于划分模块、分配任务、定义调用关系。模块间的接口与传参在这个阶段要定得十分细致明确,应编写严谨的数据字典,避免后续设计产生不解或误解。概要设计一般不是一次就能做到位,而是反复地进行结构调整。典型的调整是合并功能重复的模块,或者进一步分解出可以复用的模块。在概要设计阶段,应最大限度地提取可以重用的模块,建立合理的结构体系,节省后续环节的工作量。

概要设计文档最重要的部分是分层数据流图、结构图、数据字典以及相应的文字说明等。以概要设计文档为依据,各个模块的详细设计就可以并行展开了。

详细设计阶段:

在这个阶段,各个模块可以分给不同的人去并行设计。在详细设计阶段,设计者的工作对象是一个模块,根据概要设计赋予的局部任务和对外接口,设计并表达出模块的算法、流程、状态转换等内容。这里要注意,如果发现有结构调整(如分解出子模块等)的必要,必须返回到概要设计阶段,将调整反应到概要设计文档中,而不能就地解决,不打招呼。详细设计文档最重要的部分是模块的流程图、状态图、局部变量及相应的文字说明等。一个模块一篇详细设计文档。

概要设计文档相当于机械设计中的装配图,而详细设计文档相当于机械设计中的零件图。文档的编排、装订方式也可以参考机械图纸的方法。

我们公司对模块的认识和传统定义有所不同,认为是较大的软件功能单元才可以称作模块。这种认识使大家对概要设计和详细设计的分工产生了混乱的理解,降低了文档的可用性,应该予以纠正。

概要设计中较顶层的部分便是所谓的方案。方案文档的作用是在宏观的角度上保持设计的合理性。

有的项目采用面向对象的分析、设计方法。可能在概要设计、详细设计的分工上疑问更多。其实,面向对象的分析、设计方法并没有强调结构化方法那样的阶段性,因此一般不引入概要、详细设计的概念。如果按照公司的文档体系,非要有这种分工的话,可以将包的划分、类及对象间的关系、类的对外属性、方法及协作设计看做概要设计;类属性、方法的内部实现看做详细设计。

1.需求分析--产生软件功能规格说明书,需要确定用户对软件的需求,要作到明确、无歧义。不涉及具体实现方法。用户能看得明白,开发人员也可据此进行下面的工作(概要设计)。

2.概要设计--产生软件概要设计说明书,说明系统模块划分、选择的技术路线等,整体说明软件的实现思路。并且需要指出关键技术难点等。

3.详细设计--产生软件详细设计说明书,对概要设计的进一步细化,一般由各部分的担当人员依据概要设计分别完成,然后在集成,是具体的实现细节。理论上要求可以照此编码。

概要设计和详细设计的区别与联系

软件设计采用自顶向下、逐次功能展开的设计方法,首先完成总体设计,然后完成各有机组成部分的设计。

根据工作性质和内容的不同,软件设计分为概要设计和详细设计。概要设计实现软件的总体设计、模块划分、用户界面设计、数据库设计等等;详细设计则根据概要设计所做的模块划分,实现各模块的算法设计,实现用户界面设计、数据结构设计的细化,等等。

概要设计是详细设计的基础,必须在详细设计之前完成,概要设计经复查确认后才可以开始详细设计。概要设计,必须完成概要设计文档,包括系统的总体设计文档、以及各个模块的概要设计文档。每个模块的设计文档都应该独立成册。

详细设计必须遵循概要设计来进行。详细设计方案的更改,不得影响到概要设计方案;如果需要更改概要设计,必须经过项目经理的同意。详细设计,应该完成详细设计文档,主要是模块的详细设计方案说明。和概要设计一样,每个模块的详细设计文档都应该独立成册。

概要设计里面的数据库设计应该重点在描述数据关系上,说明数据的来龙去脉,在这里应该结合我们的一下结果数据,说明这些结果数据的源点,我们这样设计的目的和原因。详细设计里的数据库设计就应该是一份完善的数据结构文档,就是一个包括类型、命名、精度、字段说明、表说明等内容的数据字典。

概要设计里的功能应该是重点在功能描述,对需求的解释和整合,整体划分功能模块,并对各功能模块进行详细的图文描述,应该让读者大致了解系统作完后大体的结构和操作模式。详细设计则是重点在描述系统的实现方式,各模块详细说明实现功能所需的类及具体的方法函数,包括涉及到的sql语句等。

概要设计,详细设计之间的关系是什么?

Q:

我的看法:

概要设计只说明系统有多少个模块,各模块之间的接口和个模块本身的功能详细设计说明某个具体模块如何实现,粒度应该比程序略高一些

但是问题来了,各个模块之间是有层次关系的,也有先后逻辑关系。这就说明,在概要设计中,还必须考虑模块的实现细节,否则,你怎么知道这个模块下面要划分子模块?你怎么知道各子模块的调用顺序?

这就说明,概要设计和详细设计是重叠进行的,而软件工程书上说的确是顺序进行的,不知道是不是我的理解有问题。

举个例子,例如排序程序,如果设计2个模块:

一个主模块用于排序子模块用于交换2个变量,主模块调用子模块,但是子模块是怎么设计出来的呢?肯定是你先想到了用冒泡等排序方式的时候需要交换数据,这已经考虑了主模块足够多的细节,似乎属于"详细设计"了,但是目前进行的是概要设计,这就产生了我所说的重叠的情况。

A:

看看上面的帖子,有意思的居多。

上面也有朋友说到用建筑的例子来比喻。

软件的概要设计,主要是建立软件系统的整体架构,也就是我们在盖房子时候,需要先将房子的整个架子构建起来。

软件的详细设计,主要是将软件系统的各个部分的具体设计方法、逻辑、功能采用文字方式进行表述。这样在实现过程中,Coding人员原则上严格按此进行代码实现即可。

这样的一个最为简单的例证:我们可以将代码交付第三方来做。验证与跟踪采取设计来。

我看上面还有一个朋友说:快速做代码。这个本身没有值得批评之处。但只要想一下,你写的代码没有任何设计思想、文档留下的情况,一旦你离开,如何维护?重新设计吗?还是花费几倍人力去研究你写的几千/万,甚至几十万行代码?如果是这样的,你没错,关键是你们老板太对了,钱算什么。

另外的一个问题是:中国人如此聪明,但中国为什么没有出现巨型软件产品呢?个人英雄主义依然很严重,老板的短视利益行为大行其道。

概要设计及详细设计

概要设计 打招呼并判断用户是否使用该程序 1)获取数据确认用户使用该程序时提醒用户输入数据 判断用户输入数据的合法性并将合法数据存入数组 循环体1:控制第一个运算符 2)运算部分循环体2:控制第二个运算符 循环体3:控制第三个运算符 比较运算部分的结果与24:采用3个循环结构 3)输出结果打印出第一个可能的结果,终止程序 输出 没有结果时输出提示信息,终止程序 详细设计 先来分析输入部分的设计原理,作为程序的设计者,和用户的沟通是很重要的。所以开头设计了一个打招呼函数,在该函数中向用户说明程序的功能并征求用户是否开始该程序。这样的设计思路更加人性化。不仅如此,在输入数据时,设计一个循环结构,用来检测用户输入的数据是否合法,如果超出取值范围会提醒用户重新输入。这样就能够比较顺利地完成数据的获取任务。 基于穷举和简化算法结构两个出发点,该程序主体采用的是循环结构。 首先,考虑到四个数之间只能有三个运算符,每种运算符都有四种可能(加、减、乘、

除)。所以总共有4*4*4种可能的组合方式(暂不考虑家括号下的运算顺序),所以我设计了三重循环。分别以i,j,k作为计数变量,先固定i、j保持不变,k从0变到3,分别表示按照加、减、乘、除的方式依次循环,然后再让i保持不变,让k由0变到1,再将k循环从0到3循环一次,以此往复就可以把运算符所有可能的组合穷尽。 当然这是算法实现的基本过程,而在将运算方式(加、减、乘、除)与计数变量联系起来的桥梁就是函数。函数可以对两个整数进行处理,要使其根据计数变量的不同进行不同的类型的运算,就叫引入一个新的变量,在执行函数功能时让它作为开关(在该程序中,0代表加,1代表减,2代表乘,3代表除)就可以了。 最后一部分即输出部分给出了运算结果,先采用循环结构比较结果值与24是否相等(由于计算机本身精度的原因,其实只要当结果和24的差值足够小时就可以确定这种可能是可以得出24的),如果判断成立,马上输出结果并停止进一步的循环检测(减少运算量,提高效率);如果没有可能,就输出“NO SOLUTION!”提醒用户所输入的四个数无法组合形成24。在这一步就会发掘出运算部分的四维数组的优势,中括号中的数字组合刚好对应一定的运算方式,在打印过程中就有章可循了。 总的设计思路还是按照解决问题的一般逻辑问题进行的,其中不乏很多以前没有实践过的思路和方法,而且也会涉及到一些其他方面的知识,比如电脑本身的数据结构、精度等等。所以一个完整的程序需要合乎逻辑的算法,以及多方面的考虑和技术的支持。

最全面的概要设计说明书

xxxx信息系统V2.0 【模块名称】 概要设计说明书 版本号 xxx信息化建设项目组2018年05月01日

修正历史表 文档信息

目录 1.引言 (7) 1.1编写目的 (7) 1.2阅读对象 (7) 1.3术语定义 (7) 1.4参考资料 (7) 1.5图例 (7) 1.6其他 (7) 2.总体设计 (7) 2.1系统目标 (7) 2.2需求规定 (7) 2.2.1系统功能 (7) 2.2.2系统性能 (7) 2.2.3输入输出要求 (7) 2.2.4数据管理能力要求 (7) 2.2.5故障处理要求 (8) 2.2.6其他专门要求 (8) 2.3设计原则 (8)

2.5用户类及特征要求 (8) 2.6功能模块清单 (8) 2.7人工处理过程 (8) 2.8尚未解决的问题 (8) 2.9限制与约束 (8) 3.接口设计 (8) 3.1用户接口 (8) 3.2外部接口 (8) 3.3内部接口 (8) 4.全局数据结构设计 (8) 4.1数据库表名清单 (9) 4.2数据库表之间关系 (9) 4.3数据库表的详细清单 (9) 4.4视图的设计 (9) 4.5数据结构和程序的关系 (9) 4.6主要算法设计 (9) 4.7其他数据结构设计 (9) 5.系统功能说明 (9) 5.1系统功能概述 (9) 5.2系统数据流图 (9) 5.3系统外部接口 (9)

6.用户界面设计 (9) 6.1用户界面设计基本原则 (9) 6.1.1用户界面设计原则 (10) 6.1.2一般交互原则 (10) 6.1.3信息显示原则 (10) 6.1.4数据输入原则 (10) 6.2设计规范 (10) 6.2.1界面规范的总体规定 (10) 6.2.2界面一致性规范 (10) 6.2.3系统响应时间规范 (10) 6.2.4用户帮助设施规范 (10) 6.2.5出错信息和警告规范 (10) 7.运行设计 (10) 7.1运行模块设计 (10) 7.2运行控制 (10) 7.3运行时间 (10) 8.系统出错处理设计 (11) 8.1出错信息 (11) 8.2补救措施 (11) 9.安全性设计 (11) 9.1身份证认证 (11)

需求分析、概要设计、详细设计等写法(仅供参考使用)

目录 第一章概述 (1) 1.1 本课题的研究背景 (1) 1.2 本课题的研究意义 (1) 1.3 本论文的目的、内容及作者的主要贡献 (1) 1.3.1 本论文的目的 (1) 1.3.2 本论文的内容 (1) 1.3.3 作者主要贡献 (2) 1.4 国内外相近研究课题的特点及优缺点分析 (2) 1.5 现行研究存在的问题及解决办法 (2) 1.5.1 需求分析问题 (2) 1.5.2 数据库设计问题 (2) 1.5.3 三层结构设计问题 (3) 1.5.4 代码实现问题 (3) 1.5.5 页面设计问题 (3) 1.6 本课题要达到的设计目标 (3) 1.6.1 实现后台数据库的设计与实现 (3) 1.6.2 实现用户信息的管理 (3) 1.6.3 实现学生成果信息的发布与管理 (4) 1.6.4 实现对学生信息及成果信息的查询 (4) 1.6.5实现用户间学习交流的留言、评论功能 (4) 第二章系统分析 (5) 2.1 系统需求分析 (5) 2.2 采用的关键技术介绍 (6) 2.2.1 https://www.doczj.com/doc/7910781262.html,简介 (6) 2.2.2 SQL Server 2000简介 (6) 2.3 可行性分析 (7) 2.2.1 技术可行性 (7) 2.2.2 操作可行性 (7) 第三章系统概要设计 (8)

智能卡技术课程设计报告 3.1 系统总体设计 (8) 3.1.1 运行环境 (8) 3.1.2 系统流程 (8) 3.1.3 系统结构 (10) 3.2 系统接口的概要设计 (10) 3.2.1 用户接口 (10) 3.2.2 外部接口 (12) 3.3 数据库概要设计 (12) 3.3.1 逻辑结构设计 (12) 3.3.2 物理结构设计 (13) 3.4 系统出错处理设计 (14) 3.4.1 出错信息 (14) 3.4.2 补救措施 (14) 3.4.3 系统维护设计 (14) 第四章系统详细设计 (15) 4.1 表示层即系统界面的详细设计 (15) 4.1.1 母版页的详细设计 (15) 4.1.2 客户首页的详细设计 (16) 4.1.3 成果发布界面的详细设计 (17) 4.1.4 学生留言信息管理界面的详细设计 (18) 4.1.5 页面权限设置的详细设计 (19) 4.2 业务层的详细设计 (19) 4.3 数据库详细设计 (20) 4.3.1 表的详细设计 (21) 4.3.2 表间关系图 (23) 第五章系统实现 (24) 5.1 系统开发环境 (24) 5.2 系统实现 (24) 5.2.1 客户端系统实现 (24) 5.2.2 后台管理系统实现 (26) 5.3 系统运行环境要求 (27) 5.3.1 服务器端要求 (27) 5.3.2 客户端要求 (27)

(需求分析+概要设计+详细设计)文档简单范例

软件开发文档 项目名: “通讯录” 版本: α测试版 作者: ccba 编写时间:2001-8-20 文档内容: 1 需求规格说明书 2 概要设计说明书 3 详细设计说明书 文档号IM00101 需求规格说明书 1、引言: 1.1 编写目的 本文档的编写是为了确定待开发软件的功能、性能、数据、界面的需求。 1.2 项目背景 “通讯录”软件是为了提供一种功能完备,易于操作、界面美观的优秀软件。该软件由蔡文亮单独开发完成。 1.3 定义 需求规格说明书采用参考资料②标准 1.4 参考资料 ①薛华成《管理信息系统(第三版)》清华大学出版社1999.5 ②郑人杰、殷人昆、陶永雷《实用软件工程(第二版)》清华大学出版社1997.4 ③周之英《现代软件工程(基本方法篇)》科学出版社 2000.1 2、功能需求 该软件由四个主功能模块和一个扩展功能模块构成,各功能模块中规定的均为软件的基本功能,在开发过程中,开发人员可根据实际情况在满足基本功能需求的前提下增加新功能,但必须详细编写相关文档。 2.1录入、修改功能模块 该功能块主要用于数据库的数据录入和修改,考虑到通讯录的实际需要,可以放松对数据库完整性结束的控制,但从减少数据库的角度来考

虑,不容许有完全相同的纪录出现(考虑的合并,相同的纪录项)。 2.2查询功能块 本功能模块是最重要的功能块,对通讯录的操作最主要部分就是查询操作。 本功能块要求有如下功能: 1)按数据库各个属性查询 2)按数据库各个属性之间的逻辑组合查询 如:查询名称为“鸭子”且年龄为20岁的详细情况 (SQL语句表示)SELECT * FROM MESSAGER WHERE NICKNAME=“鸭子” AND AGE=20 3)按某一属性的数值范围查询及其逻辑组 如:查询年龄在20至35岁间的详细情况 (SQL语句表示)SELECT * FROM MESSAGER WHERE AGE BETWEEN 20 AND 35 4)模糊查询 同时我们要求查询结果可以按用户要求的格式来显示,如:用户能调整显示属性的个数和组合。 2.3系统安全块 通讯录的信息是个人隐私,故在软件中加入必要的安全措施。主要有以下三点: 1)登录帐号和密码的管理 2)帐户权限的控制 3)对部分登录帐号隐藏部分内容 2.4系统设置块 本部分内容主要是对软件使用时一些设置使其更利于软件的使用:主要包括以下四个方面: 1)系统界面背景和色彩设置(模仿WINNAP) 2)闹铃功能开关,即实现朋友生日提醒功能 3)记录内容项(即数据库修改通讯录上的内容项) 4)历史记录,用户可以选择是否记录下何人何时使用过该软件 2.5扩展功能块 1)网络功能:通过OLE/COM接口的调用,实现E-mail软件调用。2)帮助文档的制作(On-line help)

需求分析、概要设计、详细设计的标准格式.doc

需求分析,概要设计,详细设计的标准格式 一、开发计划 (一)引言 1、目的 说明编制开发计划的目的。 2、参考资料 列出必要的参考资料。 3、定义 列出用到的术语的定义和外文缩写的原文。 (二)概述 1、工作内容 2、主要参加人员 3、成果 列出要提交给用户的程序文件、文档或服务的名称,及非移交 成果的名称。 4、完成的最迟期限 (三)实施计划 1、任务的分解及人员分工 列出各项任务及其负责人和主要参加人员。 2、进度 列出各任务的开始日期和完成日期。 3、关键问题 列出影响整个开发项目的关键问题,技术难度、风险及处理方 案。 (四)支持条件 1、计算机系统支持 2、需要由用户承担 二、需求分析说明书 (一)引言 1、目的 说明编制需求分析说明书的目的。 2、参考资料 列出必要的参考资料。 3、定义 列出用到的术语的定义和外文缩写的原文。 (二)概述 1、目标 说明本项软件开发意图、应用目标、作用范围等,以及所开发的软件与其它软件的关系。

2、用户特点 列出使用本软件的用户类型、特点、其教育程度和技术特长。 3、约束和假定 列出本软件开发工作的假定和约束。 (三)需求规定 1、对功能的规定 根据功能模型逐项说明本软件各项功能的详细需求。 列出完成各项功能所需输入,处理,输出及所需控制等。 2、对性能的规定 包括精度、时间特性要求、灵活性。 3、数据要求 数据分为静态数据和动态数据两类。 静态数据是指在程序运行过程中一般不改变的数据; 动态数据是指在运行中发生变化、需要输入输出的数据。 (1)数据描述 (2)数据采集 (3)输入输出要求 (4)其它要求 (四)运行环境规定 (1)硬件 包括处理机、网络、输入输出设备及其它设备。 (2)软件 列出支持软件。 (3)接口 包括必要的硬件接口、软件接口、通讯接口等。 (五)关于不可能实现的用户要求的说明 三、概要设计说明书 (一)引言 1、目的 说明编制概要设计说明书目的。 2、参考资料 列出必要的参考资料。 3、定义 列出用到的术语的定义和外文缩写的原文。 (二)总体设计 1、需求规定 简述本系统的主要功能、性能等要求。 详见需求分析说明书。 2、运行环境 简述本系统的运行环境规定。 详见需求分析说明书。

软件概要设计

XX 概要设计说明书

目录

错误!未找到引用源。 关键词:能够体现文档描述内容主要方面的词汇。 摘要: 缩略语清单:对本文所用缩略语进行说明,要求提供每个缩略语的英文全名和中文解释。

1简介 1.1 目的 这部分要描述文档的目的。应该指明读者。 1.2 范围 1.2.1 软件名称 对软件命名 1.2.2 软件功能 解释软件产品将完成或不完成的功能(可以直接描述也可以参考相关文档) 1.2.3 软件应用 描述软件的应用(可直接描述也可以参考其他软件文档) 1.3实现系统环境 描述本软件的硬件应用平台(主要涉及关键器件的介绍和环境组网方式) 1.3.1 器件特性描述 本器件所支持的规格、工作模式及其异同 1.3.2 器件工作原理介绍 The description of the work principle of the device we used in our solution. 1.3.3 关键寄存器介绍 The description of the registers used in the work mode our solution. 2概要设计 2.1第0层设计描述 2.1.1 软件系统上下文定义 描述系统如何与外部实体一道组成功能实体(一般用图描述)

外部实体属性描述只限于软件设计和描述相关的属性。 2.1.2 设计思路(可选) 2.1.2.1基本设计思路 说明系统采取的基本设计思路,概要描述为什么采取本方案。 2.1.2.2设计约束 1遵循标准 描述本软件所遵循的标准、规范 2硬件限制 描述本软件系统实现的硬件限制 3技术限制 描述本软件的技术限制 2.1.2.3安全性和可靠性设计方案 4遵循标准 描述本软件所遵循的标准、规范 5硬件限制 描述本软件系统实现的硬件限制 6技术限制 描述本软件的技术限制 2.1.2.4其他 描述其他有关的设计考虑 2.2第一层设计描述 2.2.1系统架构(功能分解和物理分解) 描述组成软件系统的构件(子系统、模块),描述之间的“静态”关系。一般采用系统方框图的形式。要按照子系统组成系统,模块组成子系统的方式组织描述。 系统方框图应能规定出系统的整体架构,说明组成系统的各部分是如何搭配成一个完整系统的。 系统方框图应画成二种: 一种是功能性的,说明系统有哪些功能应由哪些功能模块来实现画出这些功能模块之间、本系统与其它接口系统之间的逻辑关系;描述它们间的接口方式,遵循的协议规范等。如果是升级类产品,在原有功能方框框图上增加、删除、修改。 另一种是物理性的,说明系统由具体的哪些软件模块来实现。

需求分析说明书、详细设计说明书、概要设计说明书样例

以下是需求分析说明书、详细设计说明书、概要设计说明书样例 需要详细资料的去 https://www.doczj.com/doc/7910781262.html,/BBS/view.asp?ID={CA9329C0-93C5-4417-9170-452FF61E8C DB}&page=1下载 XX系统概要设计说明书 目录 1. 文档介绍1 1.1 文档目的1 1.2 文档范围1 1.3 读者对象1 1.4 参考文献1 1.5 术语与缩写解释1 2. 系统概述2 3. 设计约束2 3.1需求约束2 3.2隐含约束2 4. 设计策略3 4.1扩展策略3

4.2复用策略3 4.3折衷策略3 5.系统总体结构3 5.1、系统总体结构3 5.2、子系统功能及接口4 6. 子系统的结构与功能5 6.1、TERMSERV 5 7. 功能需求追溯5 8. 环境的配置5 9.其它6 附录 6 A、与主机接口6 B、与终端接口6 1. 文档介绍 1.1 文档目的 编写该文档的目的在于从总体设计的角度明确xxxx系统的功能和处理模式,明确与银联的接口,使系

统开发人员和产品管理人员明确产品功能,可以有针对性的进行系统开发、测试、验收等各方面的工作。 1.2 文档范围 1.3 读者对象 该文档的读者为用户代表、软件分析人员、开发管理人员和测试人员。 1.4 参考文献 《xxxx系统需求说明书》 1.5 术语与缩写解释 无 2. 系统概述 XX系统是以触摸屏为主要交互工具,帮助用户以自助方式做业务查询。本系统的主要功能包括:话费 查询、新业务介绍、网点分布查询、自助终端分布查询、电信新闻、交易监控、设备维护和监控等。本系 统的设计目标是保证系统可以7*24小时安全、高效无故障运行;业务人员可以轻松完成设备和交易的监控 、管理工作;报表种类齐全,可以满足业务人员各种帐务需求。 3. 设计约束

需求分析说明书、概要设计说明书、详细设计说明书部分样例.doc

需求分析说明书、概要设计说明书、详细设计说明书部分样例 作者:rjgczj 出处:csai论坛 以下是需求分析说明书、详细设计说明书、概要设计说明书样例,需要的朋友来信联系。rjgczj@ For personal use only in study and research; not for commercial use XX系统概要设计说明书 目录 1. 文档介绍1 1.1 文档目的1 1.2 文档范围1 1.3 读者对象1 1.4 参考文献1 1.5 术语与缩写解释1 2. 系统概述2 3. 设计约束2 3.1需求约束2 3.2隐含约束2 4. 设计策略3 4.1扩展策略3 4.2复用策略3 4.3折衷策略3 5.系统总体结构3 5.1、系统总体结构3

5.2、子系统功能及接口4 6. 子系统的结构与功能5 6.1、TERMSERV 5 7. 功能需求追溯5 8. 环境的配置5 9.其它6 附录 6 A、与主机接口6 B、与终端接口6 1. 文档介绍 1.1 文档目的 编写该文档的目的在于从总体设计的角度明确xxxx系统的功能和处理模式,明确与银联的接口,使系统开发人员和产品管理人员明确产品功能,可以有针对性的进行系统开发、测试、验收等各方面的工作。 1.2 文档范围 1.3 读者对象 该文档的读者为用户代表、软件分析人员、开发管理人员和测试人员。 1.4 参考文献 《xxxx系统需求说明书》 1.5 术语与缩写解释 无 2. 系统概述 XX系统是以触摸屏为主要交互工具,帮助用户以自助方式做业务查询。本系统的主要功能包括:话费查询、新业务介绍、网点分布查询、自助终端分布查询、电信新闻、交易监控、设备维护和监控等。本系统的设计目标是保证系统可以7*24小时安全、高效无故障运行;业务人员可以轻松完成设备和交易的监控、管理工作;报表种类齐全,可以满足业务人员各种帐务需求。

大数据功能模块概要设计-V1.1Word版

第1章 系统总体架构

第2章通用组件 2.1 基础页面组件 前端页面JS框架,采用jquery为基础开发框架;为考虑对IE6,7,8的兼容性;建议版本为:1.7.2; 基于jquery的UI框架,目前流行的有:easyui 、jquery ui 、dwz;这三个各有一部分对基础页面组件的支持;(考虑到这些基础UI框架可能存在的不兼容性,建议只选择一个,对于UI框架不支持的组件,另外选择开源提供) 对于常用的基础页面组件选型如下:

2.2 基础技术组件

2.3 基础类库 J2EE服务端开发所需要的基础类库包括: apache-common 对基础类的一些扩展;包括了:commons-beanutils.jar \ commons-collections.jar \ commons-fileupload.jar \ commons-io.jar \ commons-lang.jar \ commons-lang3.jar \ commons-logging.jar json-lib 对json数据格式的解析、封装;提供将json字符串,到Bean或者List的转换;或者将Bean或者List转换为 json字符串; junit 进行单元测试的基础包;建议使用 junit4 struts2 / spring mvc MVC 的 C 层的选型 spring 业务处理逻辑层,建议使用spring3.0以上版本; ibatis / mybatis/ hibernate ORM层的选型

第3章选型 3.1 中间件 商业:weblogic、webshpere 开源:jboss、jetty、tomcat 对于中间件有要求:部署的时候,需要支持jdk6.0;如果是weblogic建议使用10.3以上版本,采用sun-jrocket的jdk; websphere 要求6.1以上版本; 3.2 数据库 3.2.1 关系型 Oracle / MySQL; 如果是oracle,要求10g以上版本,并且已经升级地理数据库 3.2.2 NoSQL mongodb / hadoop / hive /hbase /memcached/redis 3.3 底层开发框架 3.3.1 Java 服务端开发框架 struts2 + spring3+ ibatis (?mybatis)? spring3+ibatis (?mybatis) ?

教务管理系统(概要设计及详细设计)

概要设计说明书 1. 总体设计 1.1 需求规定 教务管理系统可分为学生信息管理系统和教师管理信息系统,系统开发的整体任务是实现学校教师和学生信息管理的系统化、规范化、自动化和智能化,从而达到提高学校管理效率的目的。 本阶段目的在于明确系统的数据结构和软件结构,此外总体设计还将给出内部软件和外部系统部件之间的接口定义,各个软件模块的功能说明,数据结构的细节以及具体的装配要求。 1.2 运行环境 软件基本运行环境为Windows XP环境。 1.3 基本设计概念和处理流程 概要说明书的目的在于明确系统的数据结构和软件结构,设计外部软件和内部软件的接口,说明各个软件模块的功能说明,数据结构的细节等。系统的总体处理流程如图1-1所示:

图1-1 系统的总体处理流程 1.4 系统体系结构 用一览表及框图的形式说明本系统的系统元素(各层模块、子程序、公用程序等)的划 教务管理系统 选择操作 基础维护 教学管理 报表统计 选择操作 选择操作 班级信息维护 课程信息维护 学生选课 课表查询 成绩输入 打印成绩单 学生信息维护 教 师信息维护

分,扼要说明每个系统元素的标识符和功能,分层次地给出各元素之间的控制与被控制关系。 本系统的体系架构如图1-2所示: 图1-2 系统体系架构 本系统体系结构大致可以定义为:客户机层上的表示层主要是通过Struts 框架实现的,由显示视图产生一个请求。请求被ActionServlet(控制器)接收,它在struts-config.xml文件中寻找请求的URI,找到对应的Action类后,Action类执行相应的业务逻辑。Action类执行建立在模型组件基础上的业务逻辑,模型组件是和应用程序关联的。一旦Action类处理完业务逻辑,它把控制权返回给ActionServlet,Action类提供一个键值作为返回的一部分,它指明了处理的结果。ActionServlet使用这个键值来决定在什么视图中显示Action的类处理结果。当ActionServlet把Action类的处理结果传送到指定的视图中,请求的过程也就完成了。中间业务层是通过Spring框架实现的,首先建立一个BaseAction,它继承了Action类,而其他定义的Action都要继承这个BaseAction。这个BaseAction需要导入AppContext工具类,这个AppContext需要导入Spring中org.springframework.context.support.*;这样一个继承BaseAction的Action,就可以getXXXService()的方法得到某一个service的实例-----服务定位器的设计模式。持久(PO)层是由hibernate 架构实现的,它包括关于整体数据库的hibernate.cfg.xml文件、每个表的JavaBean类和每个表的hbm.xml文件,通过Spring集成模板HibernateTemplate提供DAO 来使用PO。在Spring 的配置文件(applicationContext. xml)中配置sessionFactory的bean 来管理hibernate。

概要设计和详细设计区别

概要设计与详细设计的区别 概要设计就是设计软件的结构,包括组成模块,模块的层次结构,模块的调用关系,每个模块的功能等等。同时,还要设计该项目的应用系统的总体数据结构和数据库结构,即应用系统要存储什么数据,这些数据是什么样的结构,它们之间有什么关系。 详细设计阶段就是为每个模块完成的功能进行具体的描述,要把功能描述转变为精确的、结构化的过程描述。 概要设计阶段通常得到软件结构图 详细设计阶段常用的描述方式有:流程图、N-S图、PAD 图、伪代码等 概要设计和详细设计 在软件设计中,大家经常问到的一个问题是:概要设计应该怎样一个概要法,详细设计应该怎样一个详细法? 这个问题在公司内部经常有人问。现在陈述一下。 我们公司的研发流程是瀑布型的,这个模型中的分析、设计阶段是基于经典的结构化方法。 结构化设计方法的基本思路是:按照问题域,将软件逐

级细化,分解为不必再分解的的模块,每个模块完成一定的功能,为一个或多个父模块服务(即接受调用),也接受一个或多个子模块的服务(即调用子模块)。模块的概念,和编程语言中的子程序或函数是对应的。 这样一来,设计可以明显地划分成两个阶段: 概要(结构)设计阶段:把软件按照一定的原则分解为 模块层次,赋予每个模块一定的任务,并确定模块间调用关系和接口。 详细设计阶段:依据概要设计阶段的分解,设计每个模 块内的算法、流程等。 概要设计阶段: 在这个阶段,设计者会大致考虑并照顾模块的内部实现,但不过多纠缠于此。主要集中于划分模块、分配任务、定义调用关系。模块间的接口与传参在这个阶段要定得十分细致明确, 应编写严谨的数据字典,避免后续设计产生不解或误解。概要设计一般不是一次就能做到位,而是反复地进行结构调整。典型的调整是合并功能重复的模块,或者进一步分解出可以复用的模块。在概要设计阶段,应最大限度地提取可以重用的模块,建立合理的结构体系,节省后续环节的工作量。

概要设计说明书

1引言 (2) 1.1编写目的 (2) 1.2背景 (2) 1.3定义 (2) 1.4参考资料 (2) 2总体设计 (2) 2.1需求规定 (2) 2.2运行环境 (2) 2.3基本设计概念和处理流程 (3) 2.4结构 (3) 2.5功能器求与程序的关系 (3) 2.6人工处理过程 (3) 2.7尚未问决的问题 (3) 3接口设计 (3) 3.1用户接口 (3) 3.2外部接口 (3) 3.3部接口 (4) 4运行设计 (4) 4.1运行模块组合 (4) 4.2运行控制 (4) 4.3运行时间 (4) 5系统数据结构设计 (4) 5.1逻辑结构设计要点 (4) 5.2物理结构设计要点 (4) 5.3数据结构与程序的关系 (4) 6系统出错处理设计 (5) 6.1出错信息 (5) 6.2补救措施 (5) 6.3系统维护设计 (5)

概要设计说明书 1 引言 1.1 编写目的 本节概要设计是为了开发在线系统功能设计的,主要面向系统分析员、程序员、测试员、实施人员和最终用户。它对以后阶段的工作起指导作用。本文也是项目完成后系统验收的依据。 编写该文档的目的在于从总体设计的角度明确城市教育管理系统的功能和处理模式,服务于运营,管理的各个环节;明确用户对在管理系统的功能需求和性能需求,并将这些需求用规化的语言和规化的结构完整、准确地表达清楚,以此统一软件开发者和用户对该管理软件系统的理解和认识;可以有针对性的进行系统开发、测试、验收等各方面的工作,这是开发该城市教育管理系统的基础。 1.2 围 本城市教育资源管理系统由教育局提出,由本组人员负责开发,交由教育局使用。 1.3 定义 列出本文件中用到的专门术语的定义和缩写词的原词组。 1.4读者对象 该文档的读者为用户代表、软件分析人员、系统开发管理人员和测试人员。 1.5参考资料 编写该文档要参考的资料有: a.《项目开发计划书》 b.冰、赖涵,等.软件工程实践教程[M]. :机械工业,2009.1 c.海藩.软件工程导论[M]. :清华大学,2004. d.中国标准.计算机软件工程规化国家标准汇编2003[M]. : 中国标准,2003

(完整版)需求分析+概要设计+详细设计+数据库设计模板

附录A 软件需求分析报告文档 (1) 附录B 软件概要设计报告文档 (13) 附录C 软件详细设计报告文档 (33)

附录A 软件需求分析报告文档 1. 引言.............................................................................................................. 错误!未定义书签。 1.1编写目的 (3) 1.2项目风险 (3) 1.3文档约定 (3) 1.4预期读者和阅读建议 (3) 1.5产品范围 (4) 1.6参考文献 (4) 2. 综合描述 (4) 2.1产品的状况 (4) 2.2产品的功能 (5) 2.3用户类和特性 (5) 2.4运行环境 (5) 2.5设计和实现上的限制 (5) 2.6假设和约束(依赖) (6) 3. 外部接口需求 (6) 3.1用户界面 (6) 3.2硬件接口 (7) 3.3软件接口 (7) 3.4通讯接口 (8) 4. 系统功能需求 (8) 4.1说明和优先级 (8) 4.2激励/响应序列 (9) 4.3输入/输出数据 (9) 5. 其它非功能需求 (9) 5.1性能需求 (9) 5.2安全措施需求 (10) 5.3安全性需求 (10) 5.4软件质量属性 (10) 5.5业务规则 (10) 5.6用户文档 (10) 6. 词汇表 (11) 7. 数据定义 (11) 8. 分析模型 (12) 9. 待定问题列表 (12)

1. 简介 1.1 编写目的 此文档对《点菜系统》做了全面细致的用户需求分析,明确该软件应具有的功能、性能、界面,使系统分析人员、软件开发人员能明确用户的需求,并在此基础上进一步提出概要设计说明书和后续设计与开发。本说明书的预期读者为客户、后续开发人员、测试人员、项目管理人员等。 1.2 项目风险 具体说明本软件开发项目的全部风险承担者,以及各自在本阶段所需要承担的主要风险,首要风险承担者包括: ●任务提出者; ●软件开发者; ●产品使用者。 1.3 文档约定 描述编写文档时所采用的标准(如果有标准的话),或者各种排版约定。排版约定应该包括: ●正文风格; ●提示方式; ●重要符号; 也应该说明高层次需求是否可以被其所有细化的需求所继承,或者每个需求陈述是否都有其自己的优先级。 1.4 预期读者和阅读建议 列举本软件产品需求分析报告所针对的各种不同的预期读者,例如,可能包括: ●用户; ●开发人员; ●项目经理; ●营销人员; ●测试人员; ●文档编写入员。 并且描述了文档中,其余部分的内容及其组织结构,并且针对每一类读者提出最适合的文档阅读建议。

软件概要设计说明书范例

XX概要设计说明书

文档修改记录

填写说明 1. 系统结构的定义 本体系对整个软件系统按如下结构方式进行划分:系统子系统模块子模块 其中: (1)“系统子系统”划分属于“系统设计”,在系统设计说明书中予以描述。 (2)“子系统模块”划分属于“概要设计”,在本说明书中予以描述。 (3)“模块子模块”划分属于“详细设计”,在详细设计说明书中予以描述。如果系统相对简单,可以省略“子模块”这一层次。 2. 如果填写了系统设计说明书,则在本说明书中略过“系统子系统”划分的相关内容(即第2章)。 3. 如果系统相对简单,不需要做“系统子系统”划分,这种情况下,取消填写系统设计说明书,只须填写本说明书,直接套用“子系统模块”划分(即第3章)进行“系统模块”划分(把其中“子系统”一词替换为“系统”),并删除本说明书中“系统子系统”划分的相关内容(第2章)。

目录 1. 简介 ................................................................ 错误!未定义书签。 . 背景和目的.................................................... 错误!未定义书签。 . 范围.......................................................... 错误!未定义书签。 . 术语和缩略语.................................................. 错误!未定义书签。 2. 系统总体设计 ........................................................ 错误!未定义书签。 . 任务概述...................................................... 错误!未定义书签。 目标 .................................................... 错误!未定义书签。 需求概述 ................................................ 错误!未定义书签。 . 设计概述...................................................... 错误!未定义书签。 总体约束 ................................................ 错误!未定义书签。 系统外部接口 ............................................ 错误!未定义书签。 设计方案概述 ............................................ 错误!未定义书签。 . 系统架构设计.................................................. 错误!未定义书签。 系统的逻辑架构设计 ...................................... 错误!未定义书签。 系统的物理架构设计 ...................................... 错误!未定义书签。 . 子系统定义.................................................... 错误!未定义书签。 子系统列表 .............................................. 错误!未定义书签。 子系统间关系 ............................................ 错误!未定义书签。 3. 子系统1设计 ........................................................ 错误!未定义书签。 . 任务概述...................................................... 错误!未定义书签。 目标 .................................................... 错误!未定义书签。 需求概述 ................................................ 错误!未定义书签。 . 设计概述...................................................... 错误!未定义书签。 总体约束 ................................................ 错误!未定义书签。 子系统外部接口 .......................................... 错误!未定义书签。 设计方案概述 ............................................ 错误!未定义书签。 . 子系统架构设计................................................ 错误!未定义书签。 . 模块定义...................................................... 错误!未定义书签。

软件工程课程设计概要设计与详细设计

淮海工学院计算机工程学院实验报告书 课程名:《软件工程》 题目:图着色理论在仓库管理系统中的应用 ——概要设计与详细设计班级:网络122 学号:2012122683 姓名:叶婷

1、实验目的与要求 熟悉Visio绘图工具或PowerDesigner系统,并使用Visio或PowerDesigner系统提供的设计绘图工具,如H图、程序流程图、盒图、PAD图等完成软件工程实验项目的概要设计与详细设计文档中的层次图和程序流程图等图形绘制与文档说明。 2、实验内容 一、概要设计 1.1引言 1.1.1编写目的 近年来,生产的工业化速度迅速加快,生产的产品数量猛增,给传统的仓库管理方式手工作业带来了很大的负担,今天的仓库作业和库存控制作业已十分多样化,复杂化,靠人工去记忆去处理已十分困难,且出现错误的可能性很大。如果不能保证正确的进货、验收、质量保证及发货,就会导致浪费时间,产生库存,延迟交货,增加成本,以致失去为客户服务的机会。本文正是为解决这个问题而作。本说明书的预期读者为小中型仓库的管理员及客户和采购员。 1.1.2背景 本系统是:仓库管理系统。 本项目的任务提出者、开发者都是本人 用户:中小型仓库管理员。 软件的计算机网络:任何装有IIS的计算机作为服务器端,其他处在同一网络的计算机作为客户端。 1.1.3定义 DFD: Data Flow Diagram 数据流图,它从数据传递和加工角度,以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程,是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。 DD;Data Dictionary 数据字典:是指对数据的数据项、数据结构、数据流、数据存储、处理逻辑、外部实体等进行定义和描述,其目的是对数据流程图中的各个元素做出详细的说明。 1.1.4参考资料 1.《软件工程》---钱乐秋,赵文耘,牛军钰编著 ------ 清华大学出版社 2.《数据库系统概论》—王珊萨师煊主编 -------高等教育出版社 3.《 Java语言程序设计实用教程》董迎红张杰敏编著------ 北京大学出版社 4. 可行性研究报告 5. 需求分析说明书 1.2总体设计 1.2.1需求规定 本系统软件主要实现的功能是仓库管理员对仓库进行库存的管理,主要包括,对于生产部门送来的货物进行清点,无误后入库,对于销售部门请求的货物进行核实,无误后出库。并对仓库的

全面系统设计:详细设计和概要设计主要内容.docx

设计过程包括2个主要的规程:概要设计,详细设计。 1.概要设计:收集相关资料,确定设计目标,完成系统的架构设计。 2.详细设计:在概要设计基础上,确定接口的详细规格说明。 概要设计模板 引言(项目背景、系统任务、设计依据);总体设计(设计原则、总体结构、关键技术);系统功能设计说明;数据库设计;界面设计;系统安全设计;开发工具;系统运行环境 ?选择设计方法学:比如使用面向对象设计方式或者结构化设计方式,并且有一个成熟的 方法论作为指导。 ?子系统分解:对系统进行分层、分区等处理,得到组成系统的子系统,降低系统复杂度。 ?确定子系统的服务:定义子系统提供的服务,以及对其他子系统服务的使用情况。此处 的服务不需要对接口做详细地规格说明。 ?设计对象模型:对需求分析中产生的对象模型进行整理,添加解决域实体,根据一些设 计模式或者解决问题的需要,对系统中的实体以及它们之间的关系进行整理。 ?确定系统的构件模型:比如有哪些动态库,哪些COM组件等;确定哪些类或者文件属 于这些构件;确定构件之间的依赖关系。 ?确定系统硬件分布情况:比如是客户机/服务器,还是分布式系统,并且用模型建立它 们的关系。 ?确定软件和硬件的映射关系:哪些构件放到哪些机器上。 ?确定系统的数据管理策略:确定对实体的管理是利用内存对象、文件还是数据库方式, 并进行建模。 ?设计在系统的边界处理:比如初始化、退出、异常处理等情况下系统行为规则。 详细设计模板 详细设计是为系统的每项具体任务选择适当的技术手段和处理方法。总体设计负责构建系统整体骨架,详细设计则要考虑各个方面的部件内部细节的方案。例如系统的输入输出设计、用户界面设计、数据库设计、程序处理过程设计、网络系统设计、安全性设计等方面的内容。详细设计的基本任务 详细设计包括业务对象设计、功能逻辑设计、数据库设计和界面设计等工作。详细设计是系统实现的依据,需要考虑所有的设计细节。 (1)为每个模块进行详细的算法设计。用某种图形、表格、语言等工具将每个模块处理过程的详细算法描述出来。 (2)为模块内的数据结构进行设计。对于需求分析、概要设计确定的概念性的数据类型进行确切的定义。 (3)对数据结构进行物理设计,即确定数据库的物理结构。物理结构主要指数据库的存储记录格式、存储记录安排和存储方法,这些都依赖于具体所使用的数据库系统。 (4)其他设计:根据软件系统的类型,还可能要进行以下设计:

概要设计的写法

概要设计的写法 做软件到一定层次了,就要考虑到设计了,设计了很久,就是不系统,系统的设计需要一个记录,记录就用文档,那么对项目所有包括技术上的设计都记录下来,我们就可以理解为软件的概要设计了。在需求明确、准备开始编码之前,要做概要设计,而详细设计可能大部分公司没有做,有做的也大部分是和编码同步进行,或者在编码之后。因此,对大部分的公司来说,概要设计文档是唯一的设计文档,对后面的开发、测试、实施、维护工作起到关键性的影响。 概要设计写什么?概要设计怎么做?如何判断设计的模块是完 整的?为什么说设计阶段过于重视业务流程是个误区?以需 求分析文档还是以概要设计文档来评估开发工作量、指导开发计划 准确?结构化好还是面向对象好?以上问题的答案请在文章 中找。 二、概要设计的目的? 将软件系统需求转换为未来系统的设计;逐步开发强壮的系统构 架;使设计适合于实施环境,为提高性能而进行设计;结构 应该被分解为模块和库。 三、概要设计的任务? 制定规范:代码体系、接口规约、命名规则。这是项目小组今后共 同作战的基础,有了开发规范和程序模块之间和项目成员彼此之间 的接口规则、方式方法,大家就有了共同的工作语言、共同的工作 平台,使整个软件开发工作可以协调有序地进行。总体结构设 计:功能(加工)->模块:每个功能用那些模块实现,保证每 个功能都有相应的模块来实现;模块层次结构:某个角度的软件 框架视图;模块间的调用关系:模块间的接口的总体描述;模 块间的接口:传递的信息及其结构;处理方式设计:满足功能 和性能的算法用户界面设计;数据结构设计:详细的数 据结构:表、索引、文件;算法相关逻辑数据结构及其操作;上 述操作的程序模块说明(在前台?在后台?用视图?用过程?······)接口控制表的数据结构和使用规则其他性能设计。 四、概要设计写什么?

相关主题
文本预览
相关文档 最新文档