需求、概要设计、详细设计文档模板—软件工程

合集下载
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

需求文档结构
•1目的
•2范围
•3业务分析与建模
•4系统功能需求
– 4.1系统功能架构
– 4.2用例建模
•4.2.1用例简要描述:
•4.2.2用例角色:
•4.2.3用例前置条件:
•4.2.4用例后置条件:
•4.2.5用例事件流
–基本事件流
–备选事件流
•4.2.6用例场景(Use-Case Scenario)包括成功场景和失败场景,
场景主要是由基本流和备选流组合而成的。

•4.2.7用例非功能性需求:
•5系统非功能需求
•6系统接口
•7术语表
•8附录
OO软件设计概要说明书
1概述
系统简述、软件设计目标、参考资料、修订版本记录
这部分论述整个系统的设计目标,明确地说明哪些功能是系统决定实现而哪些时不准备实现的。

同时,对于非功能性的需求例如性能、可用性等,亦需提及。

需求规格说明书对于这部分的内容来说是很重要的参考,看看其中明确了的功能性以及非功能性的需求。

2术语表
对本文档中所使用的各种术语进行说明。

如果一些术语在需求规格说明书中已经说明过了,此处不用再重复,可以指引读者参考需求说明。

3用例
此处要求系统用用例图表述(UML),对每个用例(正常处理的情况)要有中文叙述。

OO软件设计概要说明书
•4设计概述
4.1系统结构设计
这部分要求提供高层系统结构(顶层系统结构、各子系统结构)的描述,使用方框图来显示主要的组件及组件间的交互。

最好是把逻辑结构同物理结构分离,对前者进行描述。

别忘了说明图中用到的俗语和符号。

1.系统边界
2.系统功能架构(构件模型)
3.系统逻辑架构(技术架构)
4.系统物理架构(配置模型)
5.系统数据模型(系统逻辑数据模型)
4.2系统接口设计
各种提供给用户的界面以及外部系统在此处要予以说明。

OO软件设计概要说明书
•4.4约束和假定
描述系统设计中最主要的约束,这些是由客户强制要求并在需求说明书写明的。

说明系统是如何来适应这些约束的。

实现的语言和平台也会对系统有约束,同样在此予以说明。

对于因选择具体的设计实现而导致对系统的约束,简要地描述你的想法思路,经过怎么样的权衡,为什么要采取这样的设计等等。

OO软件设计概要说明书
•5对象模型
提供整个系统的对象模型。

对象描述
在这个部分叙述每个对象的细节,它的属性、它的方法。

在这之前必须从逻辑上对对象进行组织。

OO软件设计概要说明书
•6动态模型
这部分的作用是描述系统如何响应各种事件。

一般使用顺序图和状态图。

确定不同的场景(Scenario)是第一步,不需要确定所有可能的场景,但是必须至少要覆盖典型的系统用例。

不要自己去想当然地创造场景,通常的策略是描述那些客户可以感受得到的场景。

•7非功能性设计
OO软件详细设计说明书
1概述
系统简述、软件设计目标、参考资料、修订版本记录
这部分论述整个系统的设计目标,明确地说明哪些功能是系统决定实现而哪些时不准备实现的。

同时,对于非功能性的需求例如性能、可用性等,亦需提及。

需求规格说明书对于这部分的内容来说是很重要的参考,看看其中明确了的功能性以及非功能性的需求。

2术语表
对本文档中所使用的各种术语进行说明。

如果一些术语在需求规格说明书中已经说明过了,此处不用再重复,可以指引读者参考需求说明。

3用例
此处要求系统用用例图表述(UML),对每个用例(正常处理的情况)要有中文叙述。

OO软件详细设计说明书
•4设计概述
4.1简述
这部分要求突出整个设计所采用的方法(是面向对象设计还是结构化设计)、系统的体系结构(例如客户/服务器结构)以及使用到的相应技术和工具(例如OMT、Rose)
• 4.2系统非功能描述、约束与估算:系统非功能指标的描述与估算,如:软件系统所需要的硬件资源配置要求(内存、CPU、数据存储量等要求),此配置下,系统的性能指标估算
• 4.3系统的复用计划:库、框架、模式、构件等方面的复用
• 4.4系统结构设计
•系统边界模型(系统上下文模型)
•系统功能架构:
•系统逻辑架构
•系统物理架构
•系统数据字典
•系统数据模型(系统物理数据模型)
OO软件详细设计说明书
–4.5系统接口设计
•各种提供给用户的界面
•系统外部接口设计:与外部系统的交互设计
•系统内部接口设计:各子系统、各模块间的接口设计–4.6系统约束与策略:
•描述系统的主要约束:包括需求中的功能和非功能的约束、实现方面的约束、接口方面的约束等等
•系统的一些主要策略:系统优先级策略、系统全局资源策略、系统架构风格策略、系统针对系统约束的策略等等。

OO软件详细设计说明书
–4.7对象模型设计
•对象模型:提供整个系统的对象模型,在其中应该包含
所有的系统对象。

所有对象之间的关联必须被确定并且必须指明联系的基数。

•对象描述:在这个部分叙述每个对象的细节,它的属性、它的方法。

对每个对象的每个属性详细说明:名字、类
型;对每个对象的每个方法详细说明:方法名,返回类
型,返回值,参数,用途以及使用的算法的简要说明。

OO软件详细设计说明书
–4.8动态模型设计
•这部分的作用是描述系统如何响应各种事件。

一般使用顺序图和状态图。

有需要的话也可以用活动图描述系统的主要场景的
流程图
确定不同的场景(Scenario)是第一步,不需要确定所有可能
的场景,但是必须至少要覆盖典型的系统用例。

不要自己去想
当然地创造场景,通常的策略是描述那些客户可以感受得到的
场景。

–场景(Scenarios)
(重要的业务场景)对每个场景做一则条目,包括以下内
容:
场景名:给它一个可以望文生义的名字
场景描述:简要叙述场景是干什么的以及发生的动作的顺
序。

–顺序图:描述各种事件及事件发生的相对时间顺序。

–活动图:描述场景的流程
OO软件详细设计说明书
•状态图
这部分的内容包括系统动态模型重要的部分的状态
图。

可能你想为每个对象画一个状态图,但事实上会导致太多不期望的细节信息,只需要确定系统中一些重要的对象并为之提供状态图即可。

–4.9系统非功能设计
•针对系统非功能需求进行的系统设计
标准建模语言UML (类图)
类图中的图符:
•类:表示一个类,其中第一栏是类的名,第二栏是类的属性,第三栏是类的操作。

•包:包是一种分组机制,表示一个类
图集合。

•关联:用于表示类的对象之间的关系。

其特殊形式有组成关联和聚集关联。

Operations Attributes
Class
Package
标准建模语言UML(类图)
类图中的图符:
•聚集关联:用于表示类的对象之间的关系是整体与部分的关系。

•组成关联:用于表示类的对象之间的关系:整体拥有各部分,部分与整体共存,如整体不存
在了,部分也会随之消失。

•泛化关联:泛化关系(继承关系)定义了类、包间的一般元素和特殊元素之间的分类关系。

标准建模语言UML (类图)
类图中的图符:
•依赖关系:有两个类或包元素X 、Y ,修改元素X 的定义可能会引起对另一个元素Y 的定义的修改,则称元素Y 依赖于元素X 。

•对象:类的一个实例。

•链接:用于表示对象间的关联关系的一个实例。

Values Object
将类图上出现的元素转换到Java
•关联(Association)
实体之间的一个结构化关系表明对象是相互连接的。

箭头是可选的,它用于指定导航能力。

如果没有箭头,暗示是一种双向的导航能力。

在Java中,关联转换为一个实例作用域的变量,“Java”区域所展示的代码那样。

可为一个关联附加其他修饰符。

多重性(Multiplicity)修饰符暗示着实例之间的关系。

在示范代码中,Employee可以有0个或更多的TimeCard对象。

但是,每个TimeCard只从属于单独一个Employee。

将类图上出现的元素转换到Java
依赖(Dependency)
实体之间一个“使用”关系暗示一个实体的规范发生变化后,可能影响依赖于它的其他实例。

更具体地说,它可转换为对不在实例作用域内的一个类或对象的任何类型的引用。

其中包括一个局部变量,对通过方法调用而获得的一个对象的引用(如下例所示),或者对一个类的静态方法的引用(同时不存在那个类的一个实例)。

也可利用“依赖”来表示包和包之间的关系。

相关文档
最新文档