我们应该怎么确认需求: 需求规格

一旦项目团队开始按照用户编写的原始要求进行开发，那么情况就持续了下来，这是一个崩溃的研发过程. 接受用户编写的原始需求并编写我们自己的需求规范，之所以如此重要，是因为用户编写的原始需求是出于技术实现而写的理想业务需求. 理想与现实之间始终存在差距. 我们之所以要编写自己的规范，是为了以一种实用的方式描述用户的业务需求. 那些不可行的要求被放弃或被更可行的解决方案代替. 这是需求规范的重要作用.

理论上，需求规范（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接口定义

界面的中文名称，英文名称，功能描述，参数，返回值，用户，使用频率等.

我们应该如何进行需求分析

我们应该如何进行研究: 初看

我们应该如何进行需求研究: 访问

我们应该如何进行研究: 研讨会

我们应该如何进行需求研究: 需求讨论

我们应该如何进行需求研究: 迭代

我们应该如何进行需求研究: 需求捕获（上）

我们应该如何进行需求研究: 需求捕获（如下）

我们应该如何进行需求分析: 功能角色分析和用例图

我们应该如何进行需求分析: 业务流程分析（上）

我们应该如何进行需求分析: 业务流程分析（如下）

我们应该如何进行需求分析: 用例描述

我们应该如何进行需求分析: 查询报告分析

我们应该如何进行需求分析: 子用例和扩展用例

我们应该如何进行需求分析: 动作图和状态图

我们应该如何进行需求分析: 业务领域分析

我们应该如何进行需求分析: 原始的分析方法

我们应该如何进行需求分析: 领域驱动的设计

我们应该如何进行需求分析: 非功能性需求

我们应该怎么确认需求: 需求清单

我们应如何确认需求: 需求清单示例

我们应该做什么来确认要求: 快速成型方法

我们应该怎么确认需求: 需求规格

我们应该做什么来确认要求: 审查和签名确认会议

（续）

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