如何写好需求分析：需求规格说明书(Volere版)
Atlantic System Guild（www.atlsysguild.com）公司所提供的Volere需求过程与软件需求规格说明书模板则充分利用了现代软件工程思想与技术， 是一个十分实用、完善的SRS模板。其所提供的Volere需求记录卡也十分实用，强烈推荐。
1.产品的目标
1.1 该项目工作的用户问题或背景
对引发开发任务的工作和情况的描述。同时也应描述用户希望用将要交付的软件来完成的工作。
该节内容为该项目提供了合法的理由，你应该考虑用户的问题是否严重，是否应该解决和为什么应该解决。
1.2 产品的目标
用一句话或很少的几句话来说明“我们希望该产品做什么？”换言之，即开发该产品的真正原因。
项目如果没有一个表述清晰、易于理解的目标，就会迷失在产品开发的沙漠中。产品必须带来某种优势。典型的优势是产品会增加组织在市场上的价值，减少运作成本，或提供更好的客户服务。这个优势应该是可度量的，这样才能够让您确定交付的产品是否达到目标。
2.客户、顾客和其它风险承担者
2.1 客户是为开发付费的人，并将成为所交付产品的拥有者
这一项必须给出客户的姓名，三个以内是合理的。
客户最终将接受该产品，因此必须对交付的产品满意。如果你无法找到一个客户的姓名，那么也许你就不应该构建该产品。
2.2 顾客是将花钱购买该产品的人
也给出姓名和相关的信息
2.3 其它风险承担者
其他的一些人或组织的名称，他们或者受到产品的影响，或影响产品。
- 经理或项目负责人；
- 业务领域专家；
- 技术人员；
- 系统开发者；
- 市场人员；
- 产品经理；
- 测试和质量保证人员；
- 审查员，诸如安全审查员或审计人员；
- 律师；
- 易用性专家；
- 你所处行业的专业人员。
3.产品的用户
3.1 产品的用户
产品的潜在用户或操作员的列表。针对每种类型的用户，提供以下信息：
- 用户分类
- 用户工作的任务；
- 主要相关的经验；
- 技术经验；
- 其他用户特征：包括身体、智力、工作态度、对技术的态度、教育程度、语言技能、年龄、性别等。
用户是为了完成工作而与产品交互的人，你了解用户，就越可能提交适合用户工作方式的产品。
3.2 对用户设的优先级
在每类用户后面附上一个优先级，这区别了用户的重要性和优先地位：
- 关键用户：对产品的后续成功至关重要；
- 次要用户：他们使用产品，但对产品的长期成功并无影响；
- 不重要的用户：不常用、未授权和没有技能的用户。
如果认为某些用户对产品或组织更重要，那么应该写明，因为它会影响你设计产品的方式。
4.需求限制条件
4.1 解决方案限制条件
此处明确了限制条件，它们规定了解决问题必须采取的方式。您可以认为它们是指令式的解决方案。仔细描述该解决方案，以及测试是否符合的度量标准。如果可能，您应该解释使用该解决方案的原因。
换一句话说，就是要求软件解决方案满足哪些限制条件！
4.2 实现环境
此处描述产品将被实施的技术环境和物理环境。
该环境也将成为设计解决方案时的限制条件之一。
4.3 伙伴应用
此处描述那些不属于产品的一部分，但产品却又必须与其协作的应用程序。
4.4 COTS
此处描述实现产品需求所必须使用的COTS(商业组件)。
4.5 预期的工作场地环境
此处描述用户工作和使用该产品的工作场地。此处应该描述任何可能对产品设计产生影响的工作场地特征。
4.6 开发者构建该产品需要多少时间
任何已知的最后期限，或商业机会的时限，应在此处说明。
4.7 该产品的财务预算是多少
该产品的预算，以金钱的形式或可得资源的形式说明。
5.命名标准和定义
定义项目中使用到的所有术语，包括同义词。这里的内容就是一个字典，包括在需求规格说明书中使用的所有名称的含义。这个字典应该使用你的组织或行业 使用的标准名称。这些名称也应该反映出在工作领域中当前使用的术语。该字典包括项目中用到的所有名称。请仔细地选择名称，以避免传达不同的、不期望的含 义。为每个名字写下简明扼要的定义，这些定义必须经过相应的风险承担者同意。
6.相关事实
可能对产品产生影响的外部因素，但不是命令式的需求限制条件。
7.假定
列出开发者所做的假设。
将所有的假设列在此的目的是让每一个项目成员都意识到这个假设。
8.产品的范围
8.1 工作的上下文范围
上下文范围图用来表示将要开发的系统、产品与其它系统之间的关系，以确定系统边界。
8.2 工作切分
一个事件清单，确定系统要响应的所有业务事件。清单包括：
- 事件名称
- 输入和输出
8.3 产品边界
你可以使用用例图(use-case)来确定了用户与产品之间的边界。
9.功能性需求与数据需求
9.1 功能性需求
对产品必须执行的动作的描述。
每个功能性需求必须有一个验收标准。
9.2 数据需求
与产品/系统有密切关系的主题域相关的业务对象、实体、类的说明书。
进行问题域建模，生成相应的类图。
10.观感需求
一些与产品的用户界面相关的需求描述。
11.易用性需求
11.1 易于使用
描述如何构建符合最终用户期望的产品。
11.2 学习的容易程序
学习使用该产品应该多容易的说明。通常是有学习时间来衡量。
12.性能要求
12.1 速度需求
明确完成特定任务需要的时间，这常常指响应时间。
12.2 安全性的需求
对可能造成人身伤害、财产损失和环境破坏所考虑到的风险进行量化描述。
12.3 精度需求
对产品产生的结果期望的精度进行量化描述。
12.4 可靠性和可用性需求
本节量化产品所需的可靠性。这常常表述为允许的两次失败之间无故障运行时间，或允许的总失败率。
12.5 容量需求
本节明确处理的吞吐量和产品存储数据的容量。
13.操作需求
13.1 预期的物理环境
本节明确产品将操作的物理环境，以及这种环境引起的任何特殊需求。
13.2 预期的技术环境
硬件和其它组成新产品操作环境的设备的规范。
13.3 伙伴应用程序
对产品必须与之交互的其它应用程序的描述。
14.可维护性和可移植性需求
14.1 维护该产品需要多容易
对产品作特定修改所需时间的量化描述。
14.2 是否存在一些特殊情况适用于该产品的维护
关于预期的产品发布周期和发布将采取的形式的规定。
14.3 可移植性需求
对产品必须支持的其他平台或环境的描述。
15.安全性需求
15.1 该产品是保密的吗？
关于该被授权使用该产品，以及在什么样的情况下授权等方面的描述。
15.2 文件完整性需求
关于需要的数据库和其他文件完整性方面的说明。
15.3 审计需求
关于需要的审计检查方面的说明。
16.文件和政策需求
本节包括针对社会和政策的因素的规格说明，这些因素会影响产品的可接受性。如果你开发的产品是针对外国市场的，可能要特别注意这些需求。
问一下是否产品的目标是你所不熟悉的文化环境，是否其它国家的人或其他类型的组织的人会使用该产品。人们是否有与你的文化不同的习惯、节日、迷信、文化上的社会行为规范。
17.法律需求
17.1 该产品是否受到某些法律的管制
明确该产品的法律需求的描述。
17.2 是否有一些必须符合的标准
明确适用的标准和参考的详细标准的描述。
18.Opend问题
对未确定但可能对产品产生重要影响的因素的问题描述。按照需求分析的术语还说，就是TBD（To Be Define）的问题。
19.COTS解决方案
19.1 是否有一些制造好的产品可以购买
应该调查现存产品清单，这些产品可以作为潜在的解决方案。
19.2 该产品是否可使用制造好的组件
描述可能用于该产品的候选组件，包括采购的和公司自己的产品。列出来源。
19.3 是否有一些我们可以复制的东西
其他相似产品的清单。
20.新问题
20.1 新产品会在当前环境中带来什么问题
关于新产品将怎样影响当前的实现环境的描述。
20.2 新的开发是否将影响某些已实施的系统
关于新产品将怎样与现存系统协同工作的描述。
20.3 是否我们现有的用户会受到新开发的敌对性影响
关于现有用户可能产生的敌对性反应的细节。
20.4 预期的实现环境会存在什么限制新产品的因素
关于新的自动化技术、新的组织结构方式的任何潜在问题的描述。
20.5 是否新产品会带来其他问题
确定我们可能不能处理的情况。
21.任务
21.1 为提交该产品已经做了哪些事
用来开发产品的生命周期和方法的细节。画一个高层的过程图展示各项任务和它们之间的接口，这可能是沟通这方面信息的最好办法。
21.2 开发阶段
关于每个开发阶段和操作环境中的组件的规格说明。
22.移交
22.1 我们要让已有数据和过程配合新产品，有什么特殊要求
一个移交活动的列表，一个实现的时间表。
22.2 为了新产品，哪些数据必须修改/转换
数据转换任务清单，同时确定新产品需要转换的数据。
23. 风险
23.1 当你开发该产品时，要面对什么风险
23.2 你制定了怎样的偶然紧急情况计划
24.费用
需求的其他费用是你必须投入到产品构建中去的钱或工作量。当需求规格说明书完成时，你可以使用一种估算方法来评估费用，然后以构建所需的资金或时间的形式表述出来。
25.用户文档
用户文档的清单，这些文档将作为产品的一部分交付。
26.后续版本的需求
这里记录下一些希望今后版本中实现的需求。
注：本文是译者从Atlantic System Guild公司网站www.atlsysguild.com上获得，并稍做修改。
扫一扫 微信咨询
商务合作 联系我们
微信扫一扫 
