开发的需求文档怎么写

开发的需求文档写法：1、简介；2、系统要求和功能要求；3、外部接口要求；4、非功能性需求。简介包括产品范围、产品价值、目标受众、预期用途、定义和缩略语、目录等内容。简介将成为需求文档其余部分的指南。

一、开发的需求文档写法

1、简介

在撰写需求文档时，请描述产品的目的、目标受众以及受众将如何使用它。在您的简介中，请确保包括：

• 产品范围： 这范围应与产品的总体业务目标相关，如果多个团队或承包商有权访问文档，这一点尤其重要。列出产品的好处、目的和目标。
• 产品价值： 为什么您的产品很重要？它将如何帮助您的目标受众？它将发挥什么作用，或者它将解决什么问题？问问自己，您的受众将如何从产品中找到价值。
• 目标受众：描述您的理想受众。他们将决定您产品的外观和感觉以及您如何营销它。
• 预期用途：想象一下您的受众将如何使用您的产品。列出您提供的功能以及受众根据其角色使用您的产品的所有可能方式。包含用例来说明您的愿景也是一种很好的做法。
• 定义和缩略语：每个行业或企业都有自己独特的首字母缩略词或行话。列出您在SRS中使用的术语的定义，以确保各方都理解您想说的话。
• 目录：一份详尽的需求文档可能会很长。请包括一个目录，以帮助所有参与者准确找到他们正在寻找的内容。

确保您的介绍清晰简洁，请记住，您的简介将成为需求文档其余部分的指南。

2、系统要求和功能要求

有了简介后，就该更具体了。功能要求分解了系统特性和功能，使您的系统能够按预期执行。使用概述作为参考，在填写详细信息时检查您的要求是否满足用户的基本需求。根据您的产品，有数千种功能要求需要包括。一些最常见的是：

• If/then行为
• 数据处理逻辑
• 系统工作流程
• 事务处理
• 行政职能
• 法规和合规性需求
• 性能要求
• 针对每个屏幕执行的操作详细信息

如果感觉很多，请尝试一次满足一个要求。If/then中可以包含的详细信息越多，以后需要执行的故障排除就越少。

3、外部接口要求

外部接口要求是确保系统与外部组件正确通信的功能要求类型，例如：

• 用户界面：应用程序可用性的关键，包括内容呈现、应用程序导航和用户帮助等组件。
• 硬件接口：系统软件和硬件组件之间每个接口的特征，例如支持的设备类型和通信协议。
• 软件接口： 产品与其他软件组件（包括数据库、库和操作系统）之间的连接。
• 通信接口： 您的产品将使用的通信功能的要求，例如电子邮件或嵌入式表单。

嵌入式系统依赖于外部接口要求。您应该包括屏幕布局、按钮功能以及您的产品如何依赖其他系统的描述等内容。

4、非功能性需求

需求文档的最后一部分详细介绍了非功能性需求。虽然功能需求告诉系统要做什么，但非功能需求 （NFR） 决定了系统将如何实现这些功能。例如，功能要求可能会告诉您的系统在客户订购您的产品时打印装箱单。NFR 将确保装箱单打印在 “4×6” 白纸上，这是装箱单的标准尺寸。

虽然如果您不符合 NFR，系统仍然可以工作，但您可能会将用户或利益相关者的期望置于危险之中。这些要求控制了功能要求，因此它仍然包括产品可负担性和易用性等属性。

最常见的NFR类型称为“Itys”。它们是：

• 安全：确保软件从用户那里收集的任何敏感信息受到保护所需的条件。
• 能力：产品当前和未来的存储需求，包括系统如何扩展以满足不断增长的卷需求的计划。
• 兼容性：软件的最低硬件要求，例如对操作系统及其版本的支持。
• 可靠性和可用性： 您期望用户使用您的软件的频率以及正常使用情况下的关键故障时间。
• 可扩展性：系统仍按预期执行的最高工作负载。
• 可维护性：应用程序应如何使用持续集成，以便快速部署功能和 bug 修复。
• 可用性：使用该产品是多么容易。

其他常见的非功能性需求类型包括性能、法规和环境要求。

二、需求收集的五个步骤

1、确定更改的原因

客户向软件开发团队寻求帮助通常是有原因的。企业经常面临某些可能对运营或绩效产生负面影响的挑战。开发人员必须花时间了解模拟流程和业务当前面临的挑战。考虑功能将如何帮助企业并减少当前挑战也很重要。

2、消除语言歧义

客户在解释他们的愿景或他们希望在项目中看到的功能时，可能并不总是使用正确的术语。这可能会造成混乱，在某些情况下，会导致客户不完全满意的项目。第一步可以帮助消除这种误解;但是，开发人员可能需要采取额外的步骤来进一步澄清。

3、检查角落情况

极端情况是指功能无法按预期工作的情况。尽管这些情况并不常见，但它们可能会发生并迅速影响系统的其余部分。必须详细讨论每个要求以防止这些类型的中断。

4、创建用户故事

用户情景有助于在记录需求时捕获相关信息。没有必要创建一个“完美”的故事，而是讨论该功能应该完成什么以及它如何与业务目标保持一致。软件开发团队应协助创建用户故事，然后再将其保存到项目管理系统中。

5、为每个用户故事编写一个 HTD

该过程的最后一步涉及为每个用户情景编写“如何演示”（HTD）。HTD 旨在概述向客户和开发人员证明已满足要求并令客户满意所需的步骤。这包括显示所有模棱两可的语言已被删除并说明其工作原理。

三、需求文档的重要性

1、提供明确的要求

拥有软件项目的软件需求文档为完成项目提供了明确的要求，这可以降低开发人员与其客户之间沟通不畅的机会。

2、提供蓝图

软件需求文档是软件项目的蓝图，可以帮助团队成员更好地了解项目截止日期和需求。

3、评估风险

软件需求文档评估项目的风险和收益，显示项目是否值得追求。

4、为投资者提供项目概述

软件要求文件为投资者提供了项目的概述，这可能会影响他们的投资决策。

延伸阅读

PRD的主要使用对象

PRD的主要使用对象有：开发、测试、项目经理、交互设计师、运营及其他业务人员。开发可以根据PRD获知整个产品的逻辑；测试可以根据PRD建用例；项目经理可以根据PRD拆分工作包，并分配开发人员；交互设计师可以通过PRD来设计交互细节。PRD是项目启动之前，必须要通过评审确定的最重要文档。