软件需求确认之需求规格说明书

软件需求确认之需求规格说明书

软件需求确认之需求规格说明书

曾经有项目组拿着用户编写的原始需求就开始开发，随后状况不断，一次令人崩溃的研发过程。拿着用户编写的原始需求，编写我们自己的需求规格说明书，之所以重要，就在于用户编写的原始需求，是脱离了技术实现，编写的一份十分理想的业务需求。理想与现实总是有差距，我们之所以要编写自己的需求规格说明书，就是要本着实事求是、切实可行的态度，去描述用户的业务需求。那些不可行的需求被摒弃，或者换成更加可行的解决方案。这就是需求规格说明书的重要作用。

从理论上讲，需求规格说明书（Requirement Specification）分为用户需求规格说明书和产品需求规格说明书。用户需求规格说明书是站在用户角度描述的系统业务需求，是用于与用户签字确认业务需求；产品需求规格说明书是站在开发人员角度描述的系统业务需求，是指导开发人员完成设计与开发的技术性文档。但是，我认为，用户需求规格说明书与产品需求规格说明书的差别并不大。领域驱动设计所提倡的就是要让用户、需求分析员、开发人员站在一个平台，使用统一的语言（一种混合语言），来表达大家都清楚明白的概念。从这个角度将，需求规格说明书就应当是一个，不区分用户需求规格说明书和产品需求规格说明书。

那么需求规格说明书怎么写呢？不同的公司、不同的人、不同的项目，特别是在需求分析中采用不同的方法，写出来的需求规格说明书格式都是不一样的。在这里，我给大家一个，采用RUP统一建模的方式分析需求，编写需求规格说明书的模板，供大家参考。

1．引言

1.1 编写目的

如题，描述你编写这篇文档的目的和作用。但最关键的是，详细说明哪些人可以使用这篇文档，做什么。需求规格说明书是用来做什么的？毫无疑问，首先供用户与开发公司确认软件开发的业务需求、功能范围。其次呢，当然就是指导设计与开发人员设计开发系统。当然，还包括测试人员设计测试，技服人员编写用户手册，以及其它相关人员熟悉系统。描述这些，可以帮助读者确定，阅读这篇文档是否可以从中获得帮助。

1.2 业务背景

描述业务背景，是为了读者了解与该文档相关的人与事。你可以罗列与文档相关的各种事件，也可以描写与项目相关的企业现状、问题分析与解决思路，以及触发开发该项目的大背景、政策法规，等等。

1.3 项目目标（或任务概述）

就是项目能为用户带来什么利益，解决用户什么问题，或者说怎样才算项目成功。前面提到过，这部分对项目成功作用巨大。

1.4 参考资料

参考资料的名称、作者、版本、编写日期。

1.5 名词定义

没啥可说的，就是文档中可能使用的各种术语或名词的定义与约定，大家可以根据需

要删减。

2．整体概述

这部分是对系统整体框架性地进行描述。

2.1 整体流程分析

绘制的整体行动图，及其对它的说明。

2.2 整体用例分析

绘制的整体用例图，以及对每个用例的用例说明。如果项目比较大，存在多个子系统，可以将用例图改为构件图，详细描述每个子系统及其相互的接口调用。

2.3 角色分析

一个用例图，描述系统中所有的角色及其相互关系。在随后的说明中，详细说明每个

角色的定义及其作用。

这部分还可以根据项目需要编写其它的内容，如部署方案、网络设备、功能结构、软

件架构、关键点难点技术方案，等等。

3．功能需求

3.1 功能模块（子系统）

一个一个描述系统中的每个功能模块（或子系统），即整体用例分析中的每个用例。

这部分是需求规格说明书最主要的部分。

3.1.1 用例图

绘制该模块的用例图（详见《功能角色分析与用例图》）。

3.1.2 用例说明

对用例图中的每个用例编写用例说明（详见《用例说明》）。

3.1.3 领域模型

为用例绘制领域模型，并编写领域模型说明，对每个实体进行说明。对实体的说明包

括对实体的定义、属性说明、行为说明、实体关系说明等等。如果实体间关系复杂，还要

使用对象图说明实体关系的所有情况（如《领域驱动设计》中的描述）。

4．非功能需求

这里描述的是软件对非功能需求的一般要求，即整体设计原则。那些与具体功能相关

的非功能需求应该放在用例说明的“非功能需求”部分（详见《非功能需求》）。

5．接口需求

如果项目涉及到与外部系统的接口，则编写这部分需求。

5.1 接口方案

详细描述采用什么体系结构与外部系统的接口。

5.2 接口定义

接口的中文名、英文名、功能描述、参数、返回值、使用者、使用频率，等等。