在本文中，我们将讨论需求在小程序开发中的关键作用。需求的类型是什么，开发它们的正确方法是什么？

向下滚动并获取小程序程序需求文档示例，以帮助您入门。

内容：

1、为什么要编写小程序产品需求文档

2、要求类型

3、业务需求

4、用户要求

5、系统要求

6、开发和管理需求的方法

7、良好的小程序程序开发需求文档的特征

8、小程序需求文档模板

为什么要编写小程序产品需求文档(PRD)？

您的小程序程序需要PRD的六个原因

要将您的想法变成可交付的小程序程序，您需要一个开发团队。但是找到合适的团队并不是难事。困难的部分是向开发人员清楚地解释您的小程序程序愿景，以至于他们以您的方式构想它。

编写小程序产品需求文档(PRD)的重要性在于，它可以帮助您促进您和其他利益相关者之间的思想交流。不要犹豫在工程产品需求上投入时间，因为潜在的回报是显而易见的。

让我们强调一下为什么应该为小程序启动编写PRD的核心原因：

1：增加自己的确定性。讨论您的小程序程序的要求可以让一切变得更加清晰。目标、观点、特征、约束——你的产品愿景开始成形。确定产品需求将您从模糊的陈述转变为具有详尽的截止日期、预算和质量标准的有形任务。

2：让开发人员清楚您的想法。明确的产品需求可减少您想要的小程序程序与开发人员提供的产品之间的期望差距。

3：获得及时的开发和交付。有了记录在案的小程序程序需求，您的开发团队可以更好地了解您的项目、设置优先级并减少返工。

4：确保最终应用符合您的质量期望。由于PRD中规定的验收标准，您的团队可以轻松确定您是否对交付的应用程序感到满意。

5：减少范围蔓延。高质量的需求规范可以防止您开发不必要的功能，防止您的开发团队跨目标工作，并防止您的整个开发团队变得超负荷。

6：减少开支。由于经过深思熟虑的需求有助于关注基本要素、减少返工并加快开发速度，因此它们可以为您节省资金。

根据Boehm的研究，返工可能会花费大约所有软件开发总成本的40%到50%。返工的很大一部分是由需求错误引起的。IBM曾经声称：

“没有花在需求上的时间就是花在返工上的时间——成本的200倍。”

明确要求的另一个优点是，它们允许您的团队在产品创建后不久检测缺陷，并以比后期开发或应用程序发布后更低的成本进行修复。因此，重要的是不要将开发需求视为浪费和令人沮丧的事情，而是将其视为对您的项目的投资，它将获得丰厚的回报。

产品要求类型

三种主要类型的需求

当您有了制作应用程序的想法时，您需要问自己三个主要问题：

1、为什么？为什么需要小程序程序？为了帮助人们获得您独特的体验，获得额外的收入来源，作为一项投资——您的目标是什么？

2、谁？谁会使用你的应用程序？想想你的目标用户的痛苦、问题、需求和偏好。用户希望从您的应用中获得什么解决方案？

3、如何？您将如何实现期望的业务成果并满足用户的期望？想想你的应用应该提供的功能。

这些问题的答案构成了小程序程序开发的三个主要需求层次：业务需求、用户需求和系统需求。

每个级别还具有各种功能性和非功能性需求。

功能要求与您将要实现的应用程序的操作和功能有关。

非功能性需求定义了与功能性需求无关的特征和约束。在大多数情况下，非功能性需求涉及：

1、开发产品的属性，如性能、可靠性、可用性和可用性。

2、应用程序开发过程，描述开发方法、标准、编码语言、时间限制、安全性等。

3、外部环境，考虑到您的应用与其他系统和硬件组件的连接，符合公司政策、政府法规等

如果您担心如何为小程序程序开发编写规范，请从引出您的业务需求开始。

业务需求

业务需求文档的三个主要部分

在编写您的业务需求时，请关注构建小程序程序对您的业务至关重要的原因、应用程序将带来的变化以及您期望它会产生的结果。为了让您的开发公司清楚您的产品愿景，您应该在小程序程序业务需求文档(BRD)中记录您的业务需求。

请注意，尽管我们使用术语“文档”，但这不一定是打印的纸或Google文档。您可以使用图表、数据库、电子表格或需求管理工具来存储您的需求，或者您可以将这些与传统的文本文档结合起来。

1、业务需求

背景

描述导致您产生创建小程序程序的想法的情况、项目的总体目标以及您认为它将为您的业务带来的改进。

商业机遇

与市场上现有的解决方案相比，突出您的应用程序的优势和优势。描述您的小程序程序将如何跟上市场趋势和不断发展的技术。

商业目标

以量化和可衡量的方式总结您期望从构建小程序程序中获得的好处。您的目标必须是SMART（具体、可衡量、可实现、相关且有时限）。一个目标可能是这样的：“我想在Z个月内带来X美元的收入并获得Y%的投资回报。”

成功指标

确定哪些指标将帮助利益相关者了解您的项目已取得成功。例如，对于电子商务应用程序，要在Z个月内带来X美元的收入，一个好的目标可能是在80%的订单上获得两次交叉销售。

愿景声明

您可以使用以下格式描述您的产品愿景：

对于（目标用户）

谁（需要或想要改变某事）

（您的产品名称）

是（小程序程序）

那（将提供独特的有价值的功能，关键的好处）

不同于（当前的商业模式或竞争对手）

我的产品（将您的应用与竞争应用区分开来的优势）

盈利模式

从您的项目开发开始，定义您的小程序程序将如何产生收入。您可以在我们之前的文章中查看小程序程序可能的盈利模式。

业务风险

想想可能会对您的小程序程序开发产生不利影响的情况。例如，如果您的下载量太少，您会怎么做？您主要需要估计这种风险的可能性以及它将如何影响整个项目。然后计划控制、减轻或消除风险的行动。让其他利益相关者参与决策。

假设和依赖

业务假设反映了您对实现预期业务目标的方式的观察。鉴于目标是在Z个月内带来X美元的收入，您可以假设一个新应用程序将吸引100个每月活跃用户，这些用户平均每月花费15美元。突出显示您的小程序程序开发所依赖的外部因素，例如第三方供应商、合作伙伴、其他业务项目、行业标准或法规。

2、范围和限制

功能列表

根据您的业务目标、时间和财务资源以及现有业务解决方案的问题（如果有），定义您的应用必须、应该、可以和不提供哪些功能。

初始发布范围

定义您应该首先开发哪些功能。如需帮助决定，请阅读我们关于确定小程序程序功能优先级的九种技术的文章。

后续版本的范围

本节介绍了由于其复杂性、高成本或低盈利能力而对首先开发并不那么重要的功能。您可以在未来的应用程序版本中实现它们。

限制和排除

列出您必须从项目范围中删除的功能。您可以将它们添加到后续版本中。

3、业务背景

主要利益相关者

创建以某种方式与您的项目相关的每个人的个人资料：积极参与小程序程序开发的人、依赖于其结果的人以及影响其结果的人。为了让球滚动，您可以从您的公司组织结构图开始。

项目优先事项

就功能、质量、时间表、预算和团队规模达成一致。优先考虑导致项目成功的因素并定义项目开发的限制条件。讨论您可以授予项目经理在现有限制内完成导致项目成功的任务的自由度。

部署注意事项

描述您希望对您的小程序程序进行的可能改进，以扩大其市场份额。这些可以是吸引其他国家/地区受众的额外功能，也可以是新的云数据存储，以使您的应用更具适应性。

您可以使用不同的工具来表示您的项目范围。最全面的是精益画布。它代表了业务计划中对于为所有小程序程序开发文档至关重要的部分：用户组及其主要问题、您的应用程序将提供的解决方案以及独特的价值主张(UVP)以及其他优势。在精益画布模型中，您可以描述用于吸引目标用户的渠道和关键指标，这些指标将告诉您您的业务状况。精益画布还可以帮助您确定小程序的盈利模式以及其他潜在的收入来源。

为了促进所有项目利益相关者之间的清晰沟通，在本凡科技，我们还使用了思维导图。该工具反映了小程序程序的逻辑及其主要组件之间的互连。

这是一个小程序的思维导图的简单示例：

请记住，起草小程序程序的业务需求涉及所有项目参与者。它始终是共同努力的结果。

用户要求

在确定您的业务需求之后，是时候关注用户的需求了。您需要概述用户使用您的应用程序的潜在目标以及他们将为实现这些目标而采取的行动。但是在起草用户需求时应该考虑谁的意见？

问题是，没有单一类型的应用程序用户。相反，有许多类型的用户要求不同的东西：投资者、企业主、最终用户、开发商、分销商、监管机构、营销人员等等。你的任务是倾听每个人的声音，并在不同用户群的需求之间找到平衡。

当涉及到用户需求时，明智的做法是从这三个步骤开始：

第1步—对用户进行分类。将所有利益相关者分组到用户类中。您可以根据以下标准对它们进行排序：

访问级别（访客、普通用户、付费用户、提供商、管理员）

他们执行的任务（查找、查看、阅读、选择、购买、分享、评论）

他们使用的应用程序功能（搜索、映射、排序、比较、支付等）

访问频率（每天，每月）

使用的平台（iOS或Android）

母语（或其他人口统计数据，如位置、性别、教育和家庭状况。）

第2步——确定产品拥护者。选择可以代表每组用户并将用户需求传达给项目经理的个人。成为一名优秀的产品拥护者意味着对您的应用程序将为用户带来的好处有清晰的认识。反过来，产品冠军必须是实际用户，才能完美理解用户的痛点和迫切需求。

第3步——就项目的需求决策者达成一致。就每组用户的代表与利益相关者达成一致。注意不要忽视任何利益相关者，以免抱怨最终应用程序不符合利益相关者的期望。

在确定合格的用户代表后，请他们对两种类型的用户需求提出意见。

用户要求

功能用户需求

概述用户希望在您的小程序程序中执行的任务并列出可能的用户-应用程序交互。根据这些数据，您可以推导出应用程序必须提供的核心功能，以实现这些交互。

非功能性用户需求

收集与您的小程序程序的性能、安全性、可用性等相关的用户期望。

部署注意事项

描述您希望对您的小程序程序进行的可能改进，以扩大其市场份额。这些可以是吸引其他国家/地区受众的额外功能，也可以是新的云数据存储，以使您的应用更具适应性。

在用户需求文档(URD)中记录来自用户的反馈。为此，您可以使用以下技术：

用户角色是一种有用的工具，可让您可视化目标用户。对于每个用户角色，选择姓名和照片，然后列出用户的需求、愿望和目标。写下角色将使用您的应用的关键原因。以下是我们为LinkedIn等社交媒体应用制作的用户角色示例：

用户角色示例

用户故事。逐项列出用户将在您的应用中执行的操作以实现其目标。然后按自然顺序排列这些操作，以确定典型的用户使用您的应用程序的旅程。根据您的项目范围，您可以主要概述史诗——复杂的用户操作，您可以将其分解为用户在使用您的应用程序时将采取的更小的步骤。史诗是用户故事，往往写成如下：作为一个<用户类型>，我想要<某个目标>，以便<某个原因>。

在敏捷开发中，用户故事通常被放入产品待办列表中。在协商第一个和后续版本的软件开发范围时，您和您的开发团队将考虑积压的用户故事并选择最相关的。通过安排用户故事，您可以形成产品路线图，明确定义您应该实施哪些应用功能以及何时实施。下面的示例与任何小程序程序的两个最常见的基本史诗有关：

任何小程序程序最常见的基本史诗

系统要求

软件需求规范的潜在结构

小程序程序的完整产品需求文档应包含有关您的应用程序必须如何运行的要求。抵制仅基于用户需求和业务需求仓促编写小程序程序技术设计文档的诱惑。与开发人员交谈。他们将为您提供有关在技术上是否可以实现您对应用程序功能的原始计划的反馈。在与开发人员交谈时，您将揭示项目开发的潜在威胁，并可以共同制定B计划来回避它们。

在与您的团队进行建设性对话后，在包含以下块的软件需求规范(SRS)中写下商定的需求：

系统要求

功能要求

列出开发人员可以构建的功能，以使用户能够根据您的业务需求完成任务。为此，请使用现有的思维导图或用户故事。在定义您的应用程序将做什么之后，为每个功能需求分配一个唯一的名称和编号，以及简短的描述、理由和状态。

子系统要求

从软件和硬件子系统的角度描述开发应用程序的要求。例如，如果您要构建一个健身活动跟踪应用程序，您需要为可与应用程序同步的可穿戴跟踪器编写需求。

商业规则

由于每个企业都受法律、政策和行业标准的约束，因此这些显然是SRS要求的来源。以下是需求来源的候选清单：

企业政策

政府规章

行业标准

用户角色和权限等级

If-then用户行为模型

计算算法，如果有的话

数据要求

在开发小程序程序时，您需要创建、存储、修改、显示、删除、处理和使用海量数据。要管理数据流，您需要：

概述数据实体交互的逻辑模型

在数据字典中定义实体

指定系统必须如何执行数据分析、保留或处置

选择数据报告的类型（电子表格、图表、仪表板等）

质量属性

编写明确的质量标准可确保开发人员在最终产品中满足您的期望。您需要考虑对以下方面很重要的质量属性：

您的业务和用户，例如可用性、性能和安全性（外部属性）

开发人员，例如效率、可修改性和可移植性（内部属性）

与其他利益相关者讨论哪些属性对您的应用程序的成功至关重要，并确定它们的优先级。使用适合标准为每个属性写下具体的期望——描述您的应用程序必须达到的标准的要求的量化。将质量属性转化为技术规范，并为您的团队编写验收测试，以使他们能够检查结果。

外部接口

需要小程序程序功能需求文档的这一部分，以确保您的应用程序能够与用户和外部硬件或软件系统正确通信。在SRS中，您需要写下以下要求：

用户界面。指定小程序程序屏幕的设计（字体、图标、配色方案、图像、屏幕尺寸、布局、分辨率等标准）

软件接口。描述您的应用程序与其他软件组件（包括其他应用程序、网站、库、数据库和工具）之间的交互。

硬件接口。概述每种支持的设备类型、软件和硬件之间的数据和控制交互以及要使用的通信协议。

通讯接口。在您的小程序程序的SRS中，说明您的应用程序将使用的任何通信功能的要求，包括应用程序内消息、推送通知、电子邮件和网络协议。

约束

记录限制您的小程序程序设计、操作和实施的约束条件。首先，检查您的小程序规范是否符合Apple App Store和Google Play Store的要求。此外，指定其他系统约束，例如，使用的编程语言或使用第三方API或内容的规则。

本地化要求

如果您希望您的应用程序在不同于创建应用程序的国家、文化和地理位置中使用，那么您应该设置更改要求：

货币

日期、号码、地址和电话号码格式

语言（包括国家拼写惯例、地方方言、方向）

符合法规和法律的功能

考虑到文化和政治问题的内容

时区

度量衡

其他变量

让我们仔细看看在产品和应用技术规范中用于表示系统要求的工具。

电子表格在您打算构建的应用程序功能的行和列中提供传统的演示。让我们回顾一下我们作为房地产小程序程序开发文档的一部分起草的功能需求电子表格的片段：

房地产小程序程序开发文档的一部分

您可能对以下内容感兴趣：如何制作像Zillow这样的房地产应用。

实体关系图(ERD)表示数据实体在系统内如何相互关联，以及这些实体内元素之间的连接。以下是我们在食品配送小程序程序的需求规范文档中使用的图表示例：

我们在需求规范文档中使用的图表

开发和管理需求的方法

开发和管理需求

随着项目的发展，应用程序开发的软件需求的变化是不可避免的。新要求可能来自任何地方：您的投资者可以坚持比您计划的更快获得投资回报；用户可以使用竞争对手的应用，因为您的应用没有提供他们喜欢的功能；随后的软件更新可能会对您的小程序程序开发施加额外的限制。

一劳永逸地概述小程序程序开发的软件需求很诱人，但这样做可能会导致项目失败。让我们弄清楚为什么需求开发是一个迭代过程。

您的小程序程序项目的起草要求通常是关于执行四项活动：

1：启发，或询问用户对新产品的期望，听他们说什么，观察他们做什么

2：分析或处理用户反馈以理解、分类并将此信息与可能的小程序程序需求相关联

3：规范收集，包括将模糊的用户输入转化为深思熟虑的、结构化的、带有视觉插图的书面需求文档

4：验证，即从利益相关者那里获得确认您创建的需求规范是准确和完整的

在进行分析时，您可能会意识到一些不准确的地方，从而使您回到启发式。在编写小程序产品需求文档时，您可能会遇到一些需要您进行更多分析的空白。如果利益相关者在您的需求文档中指出错误，您将不得不重写一些语句，进行重新分析，甚至进行后续民意调查。只有将这些活动交织和迭代，才能在整个开发周期内为利益相关者提供相关的小程序需求。

在本凡科技，我们通过以下步骤在发现和想法验证阶段定义并同意初始产品要求：

引出

定义业务需求

确定利益相关者群体

选择需求决策者

通过以下方式分析目标受众：

专门小组

采访

问卷

研讨会

搜索查询

社交媒体分析

论坛研究

执行文档分析

检查以前解决方案的问题

识别用户需求

分析

对竞争对手进行SWOT分析

分析想法的可行性

充实要求

优先要求

导出功能需求

制作草图和模型

创建词汇表

规格

采用需求文档模板

记录业务规则

指定非功能性需求

使用图表、电子表格和线框图记录需求

验证

创建原型

测试要求

正确的要求

定义验收标准

为了项目的成功，您需要通过健全的管理来控制需求波动。项目经理和/或业务分析师可以承担此责任。项目经理和业务分析师有不同的需求管理工具来：

跟踪不断变化的需求

执行影响分析以确定这些变化将为项目开发带来什么

跟踪需求维护

跟踪每个需求的状态

跟踪需求问题

维护需求变更的历史

良好的小程序程序开发需求文档的特征

好产品要求

由于所有利益相关者的利益在产品需求中最相交，因此您需要确保您的需求对投资者、用户和开发人员同样清晰易懂。如何构建一个小程序需求文档来满足每个人的需求？不仅是Web应用程序需求文档的内容，而且语气也可以帮助您解决这个问题。

超越一切以获得高质量的产品需求文档。讨论最适合利益相关者的详细程度、表示技术和写作风格。

在一个完美的世界中，您在PRD中规定的小程序程序要求应该是：

完全的。例如，每个功能需求都应该包含足够的信息，以便开发人员能够正确地实现它。如果您有一些差距，请将它们标记为TBD（待确定）并稍后跟进。

正确的。您和您的开发团队都应该验证您的小程序程序产品需求文档的正确性。如果需求符合技术规范、业务规则、行业标准和相关法律，则可以认为需求是正确的。

持续的。这意味着PRD中的任何要求都不应与同一PRD中的其他要求相矛盾。

可行的。在已知的员工能力、时间和预算的情况下，必须能够在手头的操作环境中实现每个产品要求。敏捷开发方法和概念原型证明可帮助您评估需求的可行性。

优先。每个需求，无论是功能需求还是用户需求，都必须按照重要性进行排序，以便为特定版本实现。

可修改。由于需求在开发过程中可能会发生变化，因此您的产品需求文档结构需要灵活。

可验证。产品要求必须是可测量的和具体的，以便测试人员可以通过测试检查它们并确定特定要求是否得到正确实施。

毫不含糊。编写小程序产品需求文档的主要原因之一是减少沟通不畅。您需要编写每个需求，以便只能以一种可能的方式对其进行解释。

我们强烈建议从开发一开始就创建一个术语表。事实是开发人员不熟悉您的业务语言，并且您可能不精通编程。对术语缺乏理解可能导致返工、错过最后期限、成本超支和不必要的辩论。

小程序需求文档模板

一些企业需要一份由深思熟虑的技术规范支持的详细需求列表，而另一些企业则满足于肤浅的方法。无论你属于哪个群体，你都必须从某个地方开始。

作为开发初始要求的指南，您可以下载我们的PDF格式的小程序程序文档示例。它提供了足够的核心信息来简化和加速开发人员进入您的项目，从而节省您的时间和金钱。

此外，如果您准备与我们的团队合作开发您的项目，您可以通过Google Forms将填写好的PRD模板发送给我们。

最后一句话

即使对于最小的项目，对初始需求有共同的理解也很重要。在某些情况下，现成的产品需求文档模板可以帮助您。但更多时候，它们只是说明性的。由于没有两个应用程序是相同的，因此其他人的PRD不可能适合您的项目。

为了完美地满足您的特定任务，您需要创建一个原始的小程序程序需求文档，这可能是一个耗时且乏味的过程。好消息是你可以把它留给专家。特别是因为他们只是一个电话。