软件开发文档的编写---软件研制任务书 (2015-03-14 17:55:03)转载▼ 标签： 软件 文档 任务书 需求 要求 分类： 软件过程改进 一. 简介 客户要

转自：http://blog.sina.com.cn/s/blog_ec1f61c60102vegd.html

软件开发文档的编写---软件研制任务书

  (2015-03-14 17:55:03)

转载▼

标签：  软件   文档   任务书   需求   要求

分类： 软件过程改进

一. 简介    

     

           客户要求我们构建一个软件系统时，通常他们会对系统应该做什么有一些想法。软件研制任务书（简称任务书）就是客户这些想法的书面化描述。    

           软件研制任务书是“软件需求分析过程”的输入，项目从任务书开始，通过对需求 （或要求） 的沟通、理解和确认， 最终形成“软件需求规格说明”，即 完成了从“系统工程”向“软件工程”的过度 。任务书 也是软件确认测试的主要依据之一，只有符合任务书 要求的软件产品，才能 通过验收并交付客户。

           任务书最主要的内容就是对客户“需求”的描述， 文档中除了“需求”，就是为理解”需求“而做的解释和说明 ，除此之外的东西都是无关紧要的，不应该出现在任务书中；然而遗憾的是，类似内容经常出现在需求描述文档中，它们的出现实质上构成了 对“需求”描述和理解的干扰。

       任务书 是 对真实世界问题的含蓄定义，它只应该描述软件”是什么“、“做什么”以及”做到什么程度“，而不应该描述”怎样做“、“如何实现”（除非它们是由客户强行规定的），这一原则和”需求规格说明“的编写要求是一样的；“需求”和"实现" 两者之前存在明显的界限，分别 是描述”需求“与描述”设计“应各自关注的东西。

       因此，需求应集中于客户和问题，而不是解决方案和实现。我们通常说，需求指定客户想要什么行为，而不是如何实现这些行为。在问题被清晰定义之前，任何对解决方案的讨论都是过早的。     

二. 模板说明： 

1. 2. 范围/引文

       标识、系统概述、文档概述、引用文档、术语和缩略语、定义和注释的说明见----- 标识&引文&概述&注释（链接）。

           系统概述部分应注意对客户需要保密的信息进行适当处理，避免违反相关要求。

3.  运行环境要求

           运行环境指的是软件” 运行时“的环境，开发环境、测试环境等不是本章涉及的的内容 。

3.1  硬件环境

（1） 对于嵌入式软件，应包括承载软件功能的主芯片（CPU、FPGA等），主要板载外设等情况的介绍；对于处理器能力、资源等方面的属性，条目化地简要介绍就可以了， 描述内容 不必过度展开， 目的是为了帮助相关读者（如评审专家）建立理解 ；

（2） 对于计算机类软件，如果对处理器能力、内存数量、网络通信能力或其他资源、能力有特殊要求的话，可在此说明。

（3）本小节和下一小节的相关内容可能和“设计约束”（见本文第5章）有关系，注意相关内容的一致性；

   

3.2  软件环境

           软件运行的操作系统，使用到的库文件，数据库，或其他软件配置项等的类型和版本信息；建议画软件系统的组成图描述。

4. 技术（任务）要求

4.1  功能

（1）对功能进行条目化描述，并对每项功能进行唯一性标识；

（2）功能性需求是软件需求中最重要的部分，相对的，其他所有的需求被合称为“非功能性需求”。功能性 需求就是描述软件“是什么”、“做什么”。其他需求都和功能性需求有关系，某种程度上是对功能性要求的补充描述。

（3）从软件要“做什么”的角度写，从“需求”和“任务”的角度写，尽量不涉及“怎样做”的问题，这是整个任务书编写中最重要的原则，具体见体系《软件设计与编程指南》中的相关描述。

4.2  性能

          

（1）对性能进行条目化描述，并对每项性能进行标识；

（2）本节中提到的 “性能”主要是软件整体的外在表现属性，如 响应时间、 实时性、处理 吞吐量、负载 能力等；

（3） 属于某一功能的性能，如RS422接口的波特率偏差性能要求，应该在对应的功能（或接口）中描述，在此处保持对该性能描述的引用即可。

4.3  输入/输出

（1）输入输出不是指接口层面的东西，而是更偏向于应用层面的数据和控制元素，是软件功能层面的数据输入或经过处理后的结果输出。例如，软件输入的图像帧的来源、格式、频度，软件接受外界中断的数量、来源、优先级等。

（2）输入/输出信息要条目化（建议表格化），有的 输入输出 在功能中已经有说明，但是在本节强调的是它的完整的属性，需要在此处比较明确地列出来。

（3） 输入/输出项 和具体功能或协议之间在描述的时候可以建立起引用关系，对理解输入/输出项以及相应的功能都有帮助。

4.4  数据处理要求

    暂无说明；

4.5  接口

（1） 标识 每个外部接口并分小节描述；

（2）外部接口的边界是控制器或FPGA的管脚，而不是板级外设（或电路）的对外接口，如DSP通过EMIF总线连接了一个芯片，通过这个芯片实现了以太网接口，那么外部接口应该识别为DSP的总线，而不是RJ45接口；

（3）但是，通知配置该芯片，响应其中断，访问其内存，芯片的确在DSP的完全控制之下，而且RJ45接口也是系统重要的外部接口，外部关注RJ45超过DSP的EMIF接口，RJ45接口也是确认测试的主要对象。因此，在描述此接口的时候，需要如实介绍这些情况，画一个框图，把关系说清楚，需求上就是明确的了；

（4）接口的描述，仅限于信号、时序等接口物理层特性相关的内容，关注接口所提供的传输机制，而和接口有一定关系的软件应用层协议应该在“功能”中描述，例如，RS422的起始位、停止位、校验位等要求属于接口的内容，而通过这个接口传输的具体数据及协议不应在本节描述。

4.6  固件

   暂无说明；

4.7  关键性要求

4.7.1  可靠性

（1）对可靠性要求分条描述并标识；

（2）本节关注的是可靠性指标和软件健壮性方面的要求，以及局部软、硬件失效的情况下，软件的表现（如功能降级要求）等。这里主要是提可靠性“要求”，建议 不要 写成为了保证可靠性而采取的具体应对方法，更不要出现“模块、部件”等设计相关的内容。本节相关的可靠性要求是要经过需求分析、设计、验证和确认过程，来逐渐具体化并得到落实的内容；

4.7.2  安全性

（1）要求参见“可靠性”一节；

（2）参照模板要求。

4.7.3  保密性

         对软件涉及到的敏感、私密信息的保护要求，避免信息的泄露或遭到主动攻击方面的表现和要求。软件开发过程以及交付后的版权和文档/产品的访问限制等内容和本节内容没有关系，不应在此描述。

5.  设计约束

（1）仔细甄别真正成为设计约束的项目，采用的开发工具或测试工具不一定是设计约束，每项设计约束都应得到确认；

（2） 设计方法、设计规则、编程规则也可以“标准”（ 7.2节）的形式出现，如果没有形成“标准”的东西，可以在本节中描述；

（3） 重用性和可移植性因对设计的影响程度而作为设计约束对待。

6.  管理要求

      对软件项目的管理机构，开发进度的要求。进度要求属于“承诺”，应考虑项目或型号的实际情况认真制定。

7.  质量控制要求

7.1  软件等级相关的要求

       规定与软件等级（如关键等级、规模等级等）的相关要求。一般客户在大纲里面有规定，否则按照体系的规则确定软件等级；

7.2  标准

         规定软件开发、测试必须遵循的（工程类）标准。根据体系、客户或项目自身的要求来确定。对设计风格、编规规范的要求必须要明确；明确测试规范。

7.3  文档

         规定必要的开发、测试文档清单以及相应的评审要求。这里都是指工程类文档，不包括管理类文档，除非用户明确要求，否则不要写的过细，或者写成按照“XX大纲的要求执行”；因为，多数时候项目具体的文档清单要在任务书之后的项目策划阶段来确定。例如，设计文档是包括概要和详细两个文档，还是合并；单元和组装测试时分开出还是合并等都不是在此阶段能确定的。

7.4  配置管理

       规定软件的配置管理要求。一般是三库管理，体系对配管的机构、职责、过程要求有明确规定；可以引用体系要求。本节内容为项目后续制定配置管理计划提供依据。

7.5  测试要求

        根据测试规范（见7.2），规定软件测试的要求；必要时规定软件测试的特殊要求（如软件必须由第三方独立测试等）。

7.6  对分承制方的要求

         当存在分承制方时，本条应描述对分 承制方的要求。若需要，可参考体系“供方协议管理（SAM）”相关规定。

8.  验收与交付 

      对于嵌入式软件，一般客户要求随整机一起交付，此时项目可以规定项目内部交付要求，具体参见体系文件“软件研制工程化程序”中验收交付的相关要求。

（1）验收准则、验收程序、验收环境；

（2）交付形式、数量、装载媒体等；

（3）规定必须交付的文档清单（参见7.3节）；

（4）需要时，规定软件的版权保护要求。

9.  维护与保障 

         本节主要描述的是对外交付（即交付客户）后对软件维护和保障活动的要求，如果系统层面对软件的维护和保障有规定，可以引用这些规定。

（1）规定软件验收（或移交）后出现问题的处理原则；

（2）说明软件改进、适应和完善性维护工作的要求；

（3）其他软件维护、培训等技术保障要求。

10.  其他要求

     对软件的可扩展性、可观察性、易测试性等软件属性方面的要求以及为以上章节内容中未明确提及的其他要求，在本章节体现。

11.  注释

     本章包括有助于了解文档的所有信息（例如：背景、术语和定义、缩略语和公式）。参见 ----- 标识&引文&概述&注释（链接） 。

---------------------------------------------------

提示信息：

a. 不要面面俱到，可以引用相关协议和手册，把相关资料组织好，为后续需求分析活动打下基础;

b.  推荐的任务书规模和代码规模的关系；小型<10页，中<15页，大< 30;

c. 一个严格的管理者，在权威的保障下，可以很快地把一套完善体系推广开来，并取得效果，如同抓学习成绩，的确大家都很辛苦，但是这样的做法并非常态；毕竟，只有理解并来自内在动力才能做好，才有长期效果，“知之者不如好 之 者，好 之 者不如乐 之 者”；

d. 文档中除了“要求”就是对要求理解而做的解释和说明 ；

e. 系统概述就是对文档理解而做的解释性铺垫，而且只是为本文档的理解而做的铺垫，不必写的过度，对不同的文件也不必一样，因为不同的文件需要的系统解释程度是不同的；

f. 给出V型图，看到 文档和开发活动之间的关联关系； 指出这种关联关系的作用---只有到V型的另一侧，才能看出之前文档编写的问题，才能体会编写文档对项目的重要意义；并提醒大家 运用 经典方法开发软件的重要意义。

g. 从概括到具体，从对真实世界问题的含蓄定义最终到软件 解决方案的要素关联。就是从需求到设计的过程。