我们应当怎样做需求确认：需求规格说明书

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

从理论上讲，需求规格说明书（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 用例图
绘制该模块的用例图（详见[url=http://fangang.iteye.com/blog/1481975]《功能角色分析与用例图》[/url]）。

3.1.2 用例说明
对用例图中的每个用例编写用例说明（详见[url=http://fangang.iteye.com/blog/1482165]《用例说明》[/url]）。

3.1.3 领域模型
为用例绘制领域模型，并编写领域模型说明，对每个实体进行说明。对实体的说明包括对实体的定义、属性说明、行为说明、实体关系说明等等。如果实体间关系复杂，还要使用对象图说明实体关系的所有情况（如[url=http://fangang.iteye.com/blog/1493720]《领域驱动设计》[/url]中的描述）。

4．非功能需求
这里描述的是软件对非功能需求的一般要求，即整体设计原则。那些与具体功能相关的非功能需求应该放在用例说明的“非功能需求”部分（详见[url=http://fangang.iteye.com/blog/1497941]《非功能需求》[/url]）。

5．接口需求
如果项目涉及到与外部系统的接口，则编写这部分需求。
5.1 接口方案
详细描述采用什么体系结构与外部系统的接口。
5.2 接口定义
接口的中文名、英文名、功能描述、参数、返回值、使用者、使用频率，等等。

[url=http://fangang.iteye.com/blog/1345099]我们应当怎样做需求分析[/url]
[url=http://fangang.iteye.com/blog/1345283]我们应当怎样做需求调研：初识[/url]
[url=http://fangang.iteye.com/blog/1392009]我们应当怎样做需求调研：拜访[/url]
[url=http://fangang.iteye.com/blog/1394911]我们应当怎样做需求调研：研讨会[/url]
[url=http://fangang.iteye.com/blog/1396971]我们应当怎样做需求调研：需求研讨[/url]
[url=http://fangang.iteye.com/blog/1403342]我们应当怎样做需求调研：迭代[/url]
[url=http://fangang.iteye.com/blog/1474362]我们应当怎样做需求调研：需求捕获（上）[/url]
[url=http://fangang.iteye.com/blog/1474368]我们应当怎样做需求调研：需求捕获（下）[/url]
[url=http://fangang.iteye.com/blog/1481975]我们应当怎样做需求分析：功能角色分析与用例图[/url]
[url=http://fangang.iteye.com/blog/1481996]我们应当怎样做需求分析：业务流程分析（上）[/url]
[url=http://fangang.iteye.com/blog/1482008]我们应当怎样做需求分析：业务流程分析（下）[/url]
[url=http://fangang.iteye.com/blog/1482165]我们应当怎样做需求分析：用例说明[/url]
[url=http://fangang.iteye.com/blog/1482171]我们应当怎样做需求分析：查询报表分析[/url]
[url=http://fangang.iteye.com/blog/1483063]我们应当怎样做需求分析：子用例与扩展用例[/url]
[url=http://fangang.iteye.com/blog/1483082]我们应当怎样做需求分析：行动图和状态图[/url]
[url=http://fangang.iteye.com/blog/1487102]我们应当怎样做需求分析：业务领域分析[/url]
[url=http://fangang.iteye.com/blog/1488291]我们应当怎样做需求分析：原文分析法[/url]
[url=http://fangang.iteye.com/blog/1493720]我们应当怎样做需求分析：领域驱动设计[/url]
[url=http://fangang.iteye.com/blog/1497941]我们应当怎样做需求分析：非功能需求[/url]
[url=http://fangang.iteye.com/blog/1502857]我们应当怎样做需求确认：需求列表[/url]
[url=http://fangang.iteye.com/blog/1502858]我们应当怎样做需求确认：一个需求列表的实例[/url]
[url=http://fangang.iteye.com/blog/1504123]我们应当怎样做需求确认：快速原型法[/url]
[url=http://fangang.iteye.com/blog/1505381]我们应当怎样做需求确认：需求规格说明书[/url]
[url=http://fangang.iteye.com/blog/1506403]我们应当怎样做需求确认：评审与签字确认会[/url]

（续）