1. 《功能要求》 -- 来源于客户要求和市场调查,是软件开发中最早期的一个环节。客户提出一个模糊的功能概念,或者要求解决一个实际问题,或者参照同类软件的一个功能。有软件经验的客户还会提供比较详细的技术规范书,把他们的要求全部列表书写在文档中,必要时加以图表解说。这份文档是需求分析的基础。
2. 《投标方案》 -- 根据用户的功能要求,经过与招标方沟通和确认,技术人员开始书写《投标方案》,方案书一般包括以下几个重要的章节: 前言 -- 项目背景、公司背景和业务、技术人员结构、公司的成功案例介绍等。 需求分析 -- 项目要求、软件结构、功能列表、功能描述、注意事项等。 技术方案 -- 总体要求和指导思想、技术解决方案、软件开发平台、网络结构体系等。 项目管理 -- 描述公司的软件开发流程、工程实施服务、组织和人员分工、开发进度控制、软件质量保证、项目验收和人员培训、软件资料文档等。 技术支持 -- 公司的技术支持和服务介绍、服务宗旨和目标、服务级别和响应时间、技术服务区域、技术服务期限、授权用户联系人等。 系统报价 -- 软、硬件平台报价列表、软件开发费用、系统维护费用等。 项目进度 -- 整个项目的进度计划,包括签署合同、项目启动、需求分析、系统分析、程序开发、测试维护、系统集成、用户验收、用户培训等步骤的时间规划。
3. 《需求分析》 -- 包括产品概述、主要概念、 *** 作流程、功能列表和解说、注意事项、系统环境等。以《功能要求》为基础,进行详细的功能分析 ( 包括客户提出的要求和根据开发经验建议的功能 ) ,列出本产品是什么,有什么特殊的概念,包括哪些功能分类,需要具备什么功能,该功能的 *** 作如何,实现的时候该注意什么细节,客户有什么要求,系统运行环境的要求等。这里的功能描述跟以后的使用手册是一致的。
4. 《技术分析》 -- 包括技术选型、技术比较、开发人员、关键技术问题的解决、技术风险、技术升级方向、技术方案评价,竞争对手技术分析等。以《需求分析》为基础,进行详细的技术分析 ( 产品的性能和实现方法 ) ,列出本项目需要使用什么技术方案,为什么,有哪些技术问题要解决 ,估计开发期间会碰到什么困难,技术方案以后如何升级,对本项目的技术有什么评价等。
5. 《系统分析》 -- 包括功能实现、模块组成、功能流程图、函数接口、数据字典、软件开发需要考虑的各种问题等。以《需求分析》为基础,进行详细的系统分析 ( 产品的开发和实现方法 ) ,估计开发期间需要把什么问题说明白,程序员根据《系统分析》,开始在项目主管的带领下进行编码。
6. 《数据库文档》 -- 包括数据库名称、表名、字段名、字段类型、字段说明、备注、字段数值计算公式等。以《系统分析》为基础,进行详细的数据库设计。必要时可以用图表解说,特别是关系数据库。
7. 《功能函数文档》 -- 包括变量名、变量初植、功能,函数名,参数,如何调用、备注、注意事项等。以《系统分析》为基础,进行详细的说明,列出哪个功能涉及多少个函数,以便以后程序员修改、接手和扩展。
8. 《界面文档》 -- 包括软件外观、界面素材、编辑工具、文件名、菜单、按钮和其它界面部件的要求,这里与软件完成后的运行界面是一致的。
9. 《编译手册》 -- 包括服务器编译环境、 *** 作系统、编译工具、 GNU 的 C++ 编译器版本信息、目录说明、程序生成、源程序文件列表、 Makefile 配置及其相关程序的对应关系列表。客户端的编译过程、编译结果、编译示例、编译环境、 *** 作系统、编译工具、源文件列表和制作安装程序的过程。
10. 《 QA 文档》 -- 包括产品简介、产品原理、产品功能列表、功能描述、功能流程、执行结果、数据库结构、测试要求等,提供给软件测试人员使用。
11. 《项目总结》 -- 包括项目简介、项目参与人员和开发时间、项目风险管理过程、项目功能列表、项目结构特点、技术特点、对项目的升级建议、对以后的项目的建议、人员素质情况等。
GitHubPages。现在大多程序员都会使用通用代码库Github,所以对于希望保存文档的程序员来说,Github是一个不错的选择,尽管很多人只是利用代码库中的readme功能来为项目提供简单的 *** 作指南,但这并非是最好的办法。
ReadtheDocs。
顾名思义,ReadtheDocs为开发人员提供了一个集中的平台来保存文档,这样用户就可以直接阅读文档了。它的工作原理有点类似GitHubpages,因为开发人员可以从他们喜欢的版本控制系统(包括Git、Bazaar、Mercurial等)中推送文档更新。
软件需求文档格式的标准写法\x0d\x0a1.引言\x0d\x0a \x0d\x0a1.1编写目的\x0d\x0a \x0d\x0a· 阐明开发本软件的目的;\x0d\x0a \x0d\x0a1.2项目背景\x0d\x0a \x0d\x0a· 标识待开发软件产品的名称、代码;\x0d\x0a \x0d\x0a· 列出本项目的任务提出者、项目负责人、系统分析员、系统设计员、程序设计员、程序员、资料员以及与本项目开展工作直接有关的人员和用户;\x0d\x0a \x0d\x0a· 说明该软件产品与其他有关软件产品的相互关系。\x0d\x0a \x0d\x0a1.3术语说明\x0d\x0a \x0d\x0a列出本文档中所用到的专门术语的定义和英文缩写词的原文。\x0d\x0a \x0d\x0a1.4参考资料(可有可无)\x0d\x0a \x0d\x0a 列举编写软件需求规格说明时所参考的资料,包括项目经核准的计划任务书、合\x0d\x0a \x0d\x0a同、引用的标准和规范、项目开发计划、需求规格说明、使用实例文档,以及相关产品\x0d\x0a \x0d\x0a的软件需求规格说明。\x0d\x0a \x0d\x0a 在这里应该给出详细的信息,包括标题、作者、版本号、发表日期、出版单位或资\x0d\x0a \x0d\x0a料来源。\x0d\x0a \x0d\x0a2.项目概述\x0d\x0a \x0d\x0a 2.1待开发软件的一般描述\x0d\x0a \x0d\x0a 描述待开发软件的背景,所应达到的目标,以及市场前景等。\x0d\x0a \x0d\x0a 2.2待开发软件的功能\x0d\x0a \x0d\x0a 简述待开发软件所具有的主要功能。为了帮助每个读者易于理解,可以使用列表或\x0d\x0a \x0d\x0a图形的方法进行描述。使用图形表示,可以采用:\x0d\x0a \x0d\x0a · 顶层数据流图;\x0d\x0a \x0d\x0a · 用例UseCase图;\x0d\x0a \x0d\x0a · 系统流程图;\x0d\x0a \x0d\x0a · 层次方框图。\x0d\x0a \x0d\x0a2.3用户特征和水平(是哪类人使用)\x0d\x0a \x0d\x0a 描述最终用户应具有的受教育水平、工作经验及技术专长。\x0d\x0a \x0d\x0a 2.4运行环境\x0d\x0a \x0d\x0a 描述软件的运行环境,包括硬件平台、硬件要求、 *** 作系统和版本,以及其他的软\x0d\x0a \x0d\x0a件或与其共存的应用程序等。\x0d\x0a \x0d\x0a 2.5条件与限制\x0d\x0a \x0d\x0a 给出影响开发人员在设计软件时的约束条款,例如:\x0d\x0a \x0d\x0a · 必须使用或避免使用的特定技术、工具、编程语言和数据库;\x0d\x0a \x0d\x0a · 硬件限制;\x0d\x0a \x0d\x0a · 所要求的开发规范或标准。\x0d\x0a \x0d\x0a3.功能需求\x0d\x0a \x0d\x0a 3.1功能划分\x0d\x0a \x0d\x0a 列举出所开发的软件能实现的全部功能,可采用文字、图表或数学公式等多种方法\x0d\x0a \x0d\x0a进行描述。\x0d\x0a \x0d\x0a3.2功能描述\x0d\x0a \x0d\x0a对各个功能进行详细的描述。\x0d\x0a \x0d\x0a4.外部接口需求\x0d\x0a \x0d\x0a4.1用户界面\x0d\x0a \x0d\x0a对用户希望该软件所具有的界面特征进行描述。以下是可能要包括的一些特征:\x0d\x0a \x0d\x0a· 将要采用的图形用户界面标准或产品系列的风格;\x0d\x0a \x0d\x0a· 屏幕布局;\x0d\x0a \x0d\x0a· 菜单布局;\x0d\x0a \x0d\x0a· 输入输出格式;\x0d\x0a \x0d\x0a· 错误信息显示格式;\x0d\x0a \x0d\x0a建议采用RAD开发工具,比如Visio,构造用户界面。\x0d\x0a \x0d\x0a4.2硬件接口\x0d\x0a \x0d\x0a 描述系统中软件产品和硬件设备每一接口的特征,以及硬件接口支持的设备、软件与硬件接口之间,以及硬件接口与支持设备之间的约定,包括交流的数据和控制信息的性质以及所使用的通信协议。\x0d\x0a \x0d\x0a4.3软件接口\x0d\x0a \x0d\x0a 描述该软件产品与其有关软件的接口关系,并指出这些外部软件或组件的名字和版本号。比如运行在什么 *** 作系统上,访问何种类型的数据库,使用什么数据库连接组件,和什么商业软件共享数据等。\x0d\x0a \x0d\x0a4.4通信接口\x0d\x0a \x0d\x0a 描述和本软件产品相关的各种通信需求,包括电子邮件、Web浏览器、网络通信协议等。\x0d\x0a \x0d\x0a4.5故障处理\x0d\x0a \x0d\x0a 对可能的软件、硬件故障以及对各项性能而言所产生的后果进行处理。\x0d\x0a \x0d\x0a5.性能需求\x0d\x0a \x0d\x0a5.1数据精确度\x0d\x0a \x0d\x0a输出结果的精度。\x0d\x0a \x0d\x0a5.2 时间特性\x0d\x0a \x0d\x0a 时间特性可包括如下几方面\x0d\x0a \x0d\x0a ·响应时间;\x0d\x0a \x0d\x0a ·更新处理时间;\x0d\x0a \x0d\x0a ·数据转换与传输时间;\x0d\x0a \x0d\x0a ·运行时间等。\x0d\x0a \x0d\x0a5.3 适应性\x0d\x0a \x0d\x0a 在 *** 作方式、运行环境、与其他软件的接口以及开发计划等发生变化时,软件的适应能力。\x0d\x0a \x0d\x0a6.其他需求\x0d\x0a \x0d\x0a列出在本文的其他部分未出现的需求。如果不需要增加其他需求,可省略这一部分。\x0d\x0a \x0d\x0a7.数据描述\x0d\x0a \x0d\x0a7.1 静态数据\x0d\x0a \x0d\x0a7.2 动态数据\x0d\x0a \x0d\x0a包括输入数据和输出数据。\x0d\x0a \x0d\x0a7.3 数据库描述\x0d\x0a \x0d\x0a 给出使用数据库的名称和类型。\x0d\x0a \x0d\x0a7.4 数据字典\x0d\x0a \x0d\x0a对于数据流图、层次方框图中出现的所有图形元素在数据字典中都要作为一个词条加以定义,使得每一个图形元素都有唯一的一个清晰明确的解释。\x0d\x0a \x0d\x0a数据字典中所有的定义必须是严密的、精确的,不可有二意性。\x0d\x0a \x0d\x0a7.5 数据采集\x0d\x0a \x0d\x0a ·列出提供输入数据的机构、设备和人员\x0d\x0a \x0d\x0a ·列出数据输入的手段、介质和设备;\x0d\x0a \x0d\x0a ·列出数据生成的方法、介质和设备。\x0d\x0a \x0d\x0a8.附录\x0d\x0a \x0d\x0a 包括分析模型,待定问题图表等。欢迎分享,转载请注明来源:内存溢出
评论列表(0条)