软件文档

需求（Requirements）

标题及做者
1 目的和范围(从技术和业务的角度)
2 利益相关者识别，例：
    项目负责人：
    高级管理人员：
    项目团队成员：
    项目的客户：
    资源管理器：
    部门经理：
    产品用户组：
    项目测试人员：
    任何受项目影响的小组：
    项目完成时受项目影响的任何小组：
    该工程的分包商：
    项目顾问：
3 市场评估和目标人口统计
4 产品概述和用例
画用例图。
5 需求
5.1 功能需求(例如产品应该作什么)
5.2 可用性需求，例：
    - 系统中全部超过0.5秒的延迟都会产生一个对话框，上面写着“请等待”。
    - 在不超过3次点击的状况下，能够从主窗口到达任何给定的系统功能。
    - 不须要鼠标，只须要键盘就能够完成任何给定的任务。
    - 全部屏幕都有一个帮助按钮。 给定屏幕上的帮助按钮必须为屏幕上的每一个控件提供至少一个“主题”。
5.3 技术要求(例如安全、网络、平台、集成、客户端)
5.4 环境要求
5.5 支持需求
5.6 交互需求(例如，产品应该如何与其余系统协做)
6 假设
可能出现但未经肯定的需求。
在订价时假设过多，极可能表明您不知道该第一时间交付什么，最好将假设做为问题从新表述给涉众。
您的目标是确认假设是否为需求。
这里还包括是否有可能影响项目的经济因素（如使用第三方的付费产品）？是否有数据质量要求？以什么形式交付？
7 约束（例如时间、成果、资源、性能、架构）
8 依赖关系
每项任务的前后顺序。
9 高级工做流计划、时间线和里程碑(经过项目计划定义更多细节)
10 评估计划和绩效指标

架构 / 设计（Architecture/Design）

软件设计是将软件需求转换为实现阶段所需的软件组件，接口和数据的表示的过程。

下面的模板是改编自 IEEE 软件设计描述推荐的实践。 更多信息请参阅 IEEE 1016

(团队名) 
(项目名) 
设计文档
名称: 
实验室: 
工做站: 
日期: 
<br/>
目录
<br/>
1. 引言
1.1 目的
指定此SDD的用意及其目标受众。 （例如“本软件设计文档描述了 XX 的架构和系统设计...”）。
1.2 边界
提供软件的描述和边界，并阐述项目的意图，目的和好处。这将为您的产品的简要描述提供基础。
1.3 概述
提供本文档的概览和结构。
1.4 参考资料（可选）
列出参考的文档。
1.5 定义和缩略语（可选）
提供可能存在的全部术语，首字母缩略词和缩写的定义，以正确解释 SDD。这些定义应该是 SDD 中最可能不为读者所知的条目。

2. 系统概述
概述项目的功能，上下文和设计。必要时提供背景信息。

3. 系统架构
3.1 架构设计
开发用来实现系统的完整功能的模块化程序结构，并解释模块之间的关系。这是对系统职责如何划分而后分配给子系统的高级概述。肯定每一个高级子系统并赋予角色或职责。描述这些子系统如何相互协做以实现所需的功能。不要过多描述关于各个子系统的细节。架构设计的主要目的是大体了解系统分解的方式和缘由，以及各个部分如何协同工做。提供一个图表，显示主要子系统和数据存储库及其联系。必要时请描述该图表。
3.2 分解描述
提供架构设计中子系统的分解。根据须要补充文字。您能够选择提供函数描述或面向对象的描述。有关函数描述，请提供顶层数据流图（DFD）和结构分解图。对于OO描述，提供子系统模型，对象图，泛化层次图（若是有），聚合层次图（若是有），接口规范和序列图。
顶层数据流图：top-level data flow diagram（DFD）
结构分解图：structural decomposition diagrams
子系统模型：subsystem model
对象图：object diagrams
泛化层次图：generalization hierarchy diagram(s)
聚合层次图：aggregation hierarchy diagram(s)
接口规范：interface specifications
序列图：sequence diagrams
3.3 设计理由
讨论选择3.1中描述的架构的缘由，包括关键议题和权衡考虑过的架构。您能够讨论考虑过的其余架构，前提是您解释了为何不选择它们。
581/5000

4. 数据设计
4.1 数据描述
解释如何将系统的信息域转换为数据结构。描述主要数据或系统实体的存储，处理和组织方式。列出所有数据库或数据存储项。
4.2 数据字典
按字母顺序列出系统实体或主要数据及其类型和说明。若是您在3.2节中提供了函数描述，请列出全部函数和函数的参数。若是您提供了OO描述，请列出对象及其属性，方法和方法的参数。

5.组件设计
在本节中，咱们将以更系统的方式仔细研究每一个组件的做用。若是您在3.2节中给出了函数描述，请以过程描述语言（PDL）或伪代码给出3.2中每一个列出的函数的算法摘要。若是您给出了OO描述，请以PDL或伪代码给出3.2中全部对象的每一个对象成员函数的算法摘要。必要时描述本地数据。

6. 人机接口设计
6.1 用户界面概述
从用户的角度描述系统的功能。说明用户如何使用您的系统来完成全部预期的功能以及将为用户显示的反馈信息。
6.2 屏幕图像
展现用户界面。这些界面能够手绘或您可使用自动绘图工具。只是让它们尽量准确。（方格纸效果很好。）
6.3 屏幕对象和动做
讨论屏幕对象和与屏幕对象关联的行为。

7. 需求矩阵
提供一个交叉引用，将组件和数据结构跟踪到 SRS（Software Requirements Specification：软件需求说明书）文档中的需求。
使用表格格式显示哪些系统组件知足SRS的哪一个功能需求。经过 SRS 中提供的数字/代码引用到功能要求。

8.附录（可选）
附录能够直接或经过引用包含在设计文档内，以提供有助于理解软件设计文档的细节。

技术（Technical）

用户（End user）

营销（Marketing）

参考

• Product requirements document - Wikipedia
• Requirements, constraints, and assumptions – MattG's Weblog
• What is the best way of formally expressing usability requirements? - Stack Overflow
• Requirements, Assumptions, and Constraints
• How to Define Project Assumptions, Constraints, Dependencies and Critical Success Factors - SaS PMO - Confluence
• Software Design Document Template Components
• sdd_template.pdf