软件设计规格说明数模板

rel="File-List" href="file:///C:%5CDOCUME%7E1%5Cliaohr%5CLOCALS%7E1%5CTemp%5Cmsohtml1%5C01%5Cclip_filelist.xml">

软件设计规格说明书模板

0.说明

本文是Brad Appleton写的软件设计规格说明书模板(原文英文)的中文阐释。本文不是对原文的逐字逐句翻译,而是摘取最重要的段句进行翻译或意译。原文链接地址为:http://www.cmcrossroads.com/bradapp/docs/sdd.html。原文的章节安排如下:

本文也尽量按照此章节来安排。

1.   介绍

   这一章介绍作者编写此模板的背景和意图。作者旨在写一个模板的模板,他给出了各部分的指导性建议,而不是一个具体的例子。

   作者认为一个完整的软件设计规格说明书应该满足下列标准:

  • 它应该能够充当新加入的项目成员的适当培训材料,告诉他们足够的信息,让他们知道项目的实现,在设计会议上说了些什么,使得他们在被要求进行编写或修改代码时不会感到一头雾水。
  •   它应该是设计者及实现者在致力于实现需求规范所要求的功能的“客观证明”。
  • 它需要足够详细,但是同时不应该由于过于难以实现或维护对设计和/或实现者施加过多的负担。

2 文档提纲

  以下是软件设计规格说明书的提纲

  • 引言(Introduction
  • 系统概述(System Overview
  • 设计考虑(Design Considerations
    • 假设与依赖性(Assumptions and Dependencies
    • 一般约束(General Constraints
    • 目标与Goals and Guidelines
    • 开发方法(Development Methods
  • 架构策略(Architectural Strategies
    • strategy-1 name or description
    • strategy-2 name or description
    • ...
  • 系统架构(System Architecture
    • component-1 name or description
    • component-2 name or description
    • ...
  • 方针与策略(Policies and Tactics
    • policy/tactic-1 name or description
    • policy/tactic-2 name or description
    • ...
  • 详细设计(Detailed System Design
    • module-1 name or description
    • module-2 name or description
    • ...
  • 词汇表(Glossary
  • 参考文献(Bibliography

上面的提纲不是排它的,可以根据需要增加自己觉得合适的章节。GlossaryBibligraphy部分可以移到文档的开头。

3 文档描述

3.1 引言

引言提供整个文档的概述:

  • 描述文档的目的
  • 描述文档的范围
  • 描述文档的目标读者
  • 提供其它相关参考文档:相关或伴随文档、前提文档、为本文档提供背景或上下文的文档、本文档的引申文档(测试计划或开发计划)
  • 定义任何重要术语或缩略语
  • 概述文档的内容

3.2 系统概述(Overview

提供一个系统的一般描述,包括其功能以及与整个系统及设计相关的事情(可能包括基本设计方法或组织的讨论)。可自由增加子章节。

3.3 设计考虑

  这一部分描述在试图设计一个完整的设计方案之前需要考虑与解决的问题。

3.3.1 假设与依赖性

描述有关软件及其使用的任何假设或依赖性。这可能包括:
  • 相关软件或硬件
  • 操作系统
  • 终端用户特点
  • 可能或很有可能的功能变化

3.3.2 一般性约束

描述对系统软件的设计产生重要影响的总体限制或约束。包括但不限于:

  • 硬件或软件环境
  • 终端用户环境
  • 资源的可用性与变动性
  • 遵循的标准
  • 互操作需求
  • 接口/协议要求
  • 数据仓库与发布需求
  • 安全性需求
  • 内存或其它容量限制
  • 性能需求
  • 网络通信
  • 审核与验证需求(测试)
  • 其它说明质量目标的方法
  • 其它需求规范中描述的需求

3.3.3 目标与指导方针

描述任何统治系统软件设计的目标、指南、原则或前提条件。这些目标可能是:

  •   KISS原则(保持近乎愚蠢地简单)
  • 重点关注速度与内存使用比

对于每一目标或指南,除非非常明显的,应描述其作为目标的原因

 

3.3.3 开发方法

简单描述这一软件设计的方法或方式。如果多个正式的方法被采用,包括这些方法的更详细的参考。

3.4 架构策略

 描述任何影响到整个系统组织与高层结构的设计决定或策略。这些策略应该包括对于整个系统结构主要的抽象与机制的洞见。描述应选择每一决定或策略的原因(并讨论其它方案)。这些决定可能包括以下方面:


  • 使用一种特定的产品(程序语言、数据库、库等)
  • 对已有软件组建的重用
  • 扩展与增强软件的将来计划
  • 用户接口典范
  • 硬件或软件接口典范
  • 故障检测与恢复
  • 内存管理策略
  • 外部数据库与数据存储管理持久化策略
  • 分布式数据或通过网络控制
  • 控制的一般方法
  • 并行与同步机制
  • 通信机制
  • 其它资源管理

3.4 系统架构

这一部分应提供系统的功能与职责怎样分解为子系统或组建的高层概览。注意不要过于详细描述单个子系统或组件(下面有专门章节来详细描述组件)。这里主要的目的是获取整个系统怎样及为什么这样分解的基本理解,以及不同部分怎样协同工作来提供期待的功能。

rel="File-List" href="file:///C:%5CDOCUME%7E1%5Cliaohr%5CLOCALS%7E1%5CTemp%5Cmsohtml1%5C01%5Cclip_filelist.xml">
3.4.1 子系统架构

   如果某一组建需要更详细讨论,可以在这一部分描述。

3.5 方针与策略(Policies and Tactics)

  • 特定产品的选择(编译器、解析器、数据库、函数库等)
  • 工程权衡
  • 编码指南与规范
  • 一个或多个子系统、模块、子流程的协议
  • 特定算法或设计模式的选择
  • 保证整个需求可跟踪性的计划
  • 软件测试计划
  • 软件维护计划
  • 终端用户、软件、硬件和通信的接口
  • 源代码的组织
  • 怎样部署发布系统

3.6 详细设计

在系统架构中描述的大多数组件将需要更详细的讨论,更低层次的子组件可能也需要描述。这种讨论覆盖以下属性:

  • 分类(组件的种类,如子系统、模块、类、包、函数、文件等)
  • 定义(组件的具体目的和语义)
  • 职责(组件的主要职责和主要行为)
  • 约束(任何相关的假设、限制或约束)
  • 构成(子组件的使用和意义描述)
  • 使用/相互作用(与其它组件协作的描述)
  • 资源(任何实体管理、影响或需要的资源)
  • 处理(组件如何履行任务实现其职责的描述。应该包括任何使用的算法、状态变化、相应时间或空间复杂性、并发性、创建方法、初始化和清除以及异常条件处理)
  • 接口/输出(组件提供的服务:资源、数据、类型、常数、子程序、异常)

详细设计还可能包括详细的子系统设计部分。

3.7 词汇表

术语和概念定义

3.8 参考文献

引用或相关的出版物

  • 0
    点赞
  • 3
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值