如何编写需求分析: 需求规范（Volere版本）

Atlantic System Guild（）公司提供的Volere需求过程和软件需求规范模板充分利用了现代软件工程的思想和技术，是一种非常实用和完善的SRS模板. 它提供的Volere需求记录卡也非常实用，强烈建议使用.

1.1用户问题或项目工作背景

引起开发任务的工作和情况的描述. 它还应该描述用户想要对要交付的软件进行的操作.

本节提供了该项目的法律依据. 您应该考虑用户的问题是否严重，是否应该解决以及为什么要解决.

1.2产品目标

使用一句话或几句话来解释“我们希望该产品做什么？”换句话说数据需求规格说明书，开发产品的真正原因.

如果该项目没有明确且易于理解的目标，那么它将迷失在产品开发的沙漠中. 该产品必须带来一些优势. 产品的典型优势是产品可以提高组织在市场中的价值，降低运营成本或提供更好的客户服务. 此优势应该是可衡量的，以便您可以确定所交付的产品是否达到其目标.

2.1客户是为开发付费的人，并将成为交付产品的所有者

此商品必须提供客户的姓名，三位数以内.

客户最终将接受产品，因此必须对交付的产品感到满意. 如果找不到客户的名字，那么也许您不应该生产该产品.

2.2客户是愿意花钱购买产品的人

还提供了名称和相关信息

2.3其他冒险者

受产品影响或影响产品的其他人或组织的名称.

经理或项目负责人；业务领域专家；技术人员；系统开发人员；营销人员；产品经理；测试和质量保证人员；审核者，例如安全审核者或审核员；；可用性专家；您所在行业的人员.

3.1产品的用户

该产品的潜在用户或操作员的列表. 对于每种类型的用户，请提供以下信息:

用户工作的用户分类任务；主要相关经验；技术经验；其他用户特征: 包括身体，智力，工作态度，对技术的态度，受教育程度，语言技能，年龄，性别等.

用户是与产品互动以完成工作的人. 您对用户的了解越多，就越有可能提交适合用户工作方式的产品.

3.2为用户设置的优先级

每种类型的用户都具有优先级，这区分了用户的重要性和优先级:

主要用户: 对产品后续成功至关重要；二级用户: 他们使用该产品，但不会影响该产品的长期成功；不重要的用户: 不常用，未经授权和不熟练的用户.

如果您认为某些用户对产品或组织更重要，则应该编写它，因为这会影响您设计产品的方式.

4.1解决方案限制

在此处明确定义了限制，它们指定了解决问题所必须使用的方法. 您可以将它们视为当务之急. 仔细描述解决方案和测试符合的指标. 如果可能的话，您应该解释使用此解决方案的原因.

换句话说，软件解决方案需要什么约束！

4.2实施环境

此处介绍了将要实施该产品的技术环境和物理环境.

环境也将成为设计解决方案时的限制条件之一.

4.3合作伙伴申请

这描述了不属于产品一部分的应用程序，但是产品必须与之协作.

4.4 COTS

这描述了必须用于满足产品要求的COTS（商业组件）.

4.5预期的工作环境

此处是用户在其中工作和使用产品的工作站点的描述. 这应该描述任何可能影响产品设计的工作场所特征.

4.6开发人员构建产品需要多长时间

应在此处注明任何已知的截止日期或商机的时限.

4.7产品的财务预算是什么

产品预算以金钱或可用资源的形式表示.

定义项目中使用的所有术语，包括同义词. 这里的内容是一个字典，包括需求规范中使用的所有名称的含义. 该词典应使用您的组织或行业使用的标准名称. 这些名称还应反映工作领域中当前使用的术语. 词典包括项目中使用的所有名称. 请仔细选择名称，以避免传达不同的含义. 为每个名称编写简洁的定义. 这些定义必须得到适当的利益相关者的批准.

可能影响产品但不是强制性要求的外部因素.

列出开发人员的假设.

在此处列出所有假设的目的是使每个项目成员都知道该假设.

8.1工作环境

上下文范围图用于表示系统，产品和要确定系统边界的其他系统之间的关系.

8.2工作细分

事件列表，用于确定系统将响应的所有业务事件. 列表包括:

事件名称输入和输出

8.3产品边界

您可以使用用例图（用例）来确定用户与产品之间的界限.

9.1功能要求

产品必须执行的操作的说明.

每个功能要求必须有一个验收标准.

9.2数据要求

与与产品/系统紧密相关的主题领域相关的业务对象，实体和类的规范.

为问题域建模并生成相应的类图.

与产品用户界面有关的要求的描述.

11.1易于使用

描述如何构建满足最终用户期望的产品.

11.2简单易学的程序

了解使用该产品应该有多么容易. 通常用学习时间来衡量.

12.1速度要求

定义完成特定任务所需的时间，通常称为响应时间.

12.2安全要求

定量描述可能导致人身伤害，财产损失和环境破坏的风险.

12.3精度要求

定量描述产品产生的结果的预期准确性.

12.4可靠性和可用性要求

此部分量化了产品所需的可靠性. 这通常表示为两次故障之间允许的无故障运行时间，或允许的总故障率.

12.5容量要求

此部分明确定义了吞吐量和产品存储容量.

13.1预期的物理环境

本节指定了产品将在其中运行的物理环境，以及由此环境引起的任何特殊要求.

13.2预期的技术环境

构成新产品操作环境的硬件和其他设备的规范.

13.3合作伙伴申请

产品必须与之交互的其他应用程序的说明.

14.1维护产品有多么容易

对产品进行特定修改所需的时间的定量描述.

14.2是否有适用于本产品维护的特殊情况

关于预期产品发布周期以及发布形式的规定.

14.3便携性要求

产品必须支持的其他平台或环境的描述.

15.1产品是机密的吗？

产品授权使用的描述以及在何种情况下授权使用该产品.

15.2文件完整性要求

有关所需和其他文件的完整性的说明.

15.3审核要求

有关所需审核检查的说明.

本节包括影响产品可接受性的社会和政策因素的规范. 如果您为国外市场开发产品，则可能需要特别注意这些需求.

询问产品的目标是否是您不熟悉的文化环境，以及其他国家或其他类型组织的人是否会使用该产品. 人们是否有与您的文化不同的习惯，节日，迷信和文化社会规范？

17.1产品受某些法律规范

澄清产品法律要求的描述.

17.2是否必须满足一些标准

适用标准的描述和所引用的详细标准.

描述可能对产品产生重要影响的不确定因素的问题. 根据需求分析的术语，这是待定的问题.

19.1是否有一些可以购买的制成品

应调查现有产品清单. 这些产品可用作潜在的解决方案.

19.2产品是否可以使用制造的组件

描述可能用于产品的候选组件，包括购买的产品和公司自己的产品. 列出来源.

19.3有什么可以复制的吗

其他类似产品的列表.

20.1新产品将在当前环境中带来什么问题

有关新产品将如何影响当前实施环境的说明.

20.2新开发会影响某些已实施的系统

描述新产品如何与现有系统配合使用.

20.3我们现有的用户是否会受到新开发项目的敌意

有关现有用户可能发生的敌对反应的详细信息.

20.4哪些因素将在预期的实施环境中限制新产品

有关新自动化技术和新组织结构的任何潜在问题的描述.

20.5新产品是否会带来其他问题

确定我们可能无法处理的情况.

21.1提交此产品做了什么

生命周期的详细信息以及用于开发产品的方法. 绘制一个高级流程图以显示任务及其之间的接口可能是传达此信息的最佳方法.

21.2开发阶段

关于每个开发阶段和操作环境中组件的规范.

22.1我们需要什么特殊要求才能使现有数据和流程与新产品相匹配

移交活动列表，实施时间表.

22.2新产品必须修改/转换哪些数据

数据转换任务列表，同时确定要为新产品转换的数据.

23.1开发此产品时，您应该面对什么风险

23.2您制定了什么意外的应急计划

其他需求成本是您必须在产品构造上进行投资的金钱或工作量. 需求规格说明完成后，您可以使用一种估算方法来估算成本数据需求规格说明书，然后以所需的资金或建设时间的形式来表达.

将作为产品一部分提供的用户文档列表.

以下是我们希望在将来的版本中实现的一些要求.

注意: 本文是由译者从Atlantic System Guild网站上获得的，经过细微修改.

本文来自电脑杂谈，转载请注明本文网址：
https://www.pc-fly.com/a/ruanjian/article-283131-1.html