如何编写移动应用产品需求文档

在本文中，我们将讨论需求在移动应用程序开发中的关键作用。 需求的类型是什么，开发它们的正确方法是什么？ 向下滚动并获取移动应用要求文档示例以帮助您入门。

内容：

1. 为什么要编写移动应用产品需求文档
2. 需求类型
3. 业务需求
4. 用户要求
5. 系统要求
6. 开发和管理需求的方法
7. 一个好的移动应用开发需求文档的特征
8. 移动应用需求文档模板

为什么要编写移动应用产品需求文档 (PRD)？

要将您的想法变成可交付的移动应用程序，您需要一个开发团队。 但找到合适的团队并不是难事。 困难的部分是向开发人员清楚地解释您的移动应用程序愿景，以便他们按照您的方式进行构想。

编写移动应用程序产品需求文档 (PRD) 可帮助您促进您与其他利益相关者之间的交流。 不要犹豫在工程产品需求上投入时间，因为潜在的回报是显而易见的。

• 增加你自己的确定性。 讨论您的移动应用程序的要求会使一切变得更加清晰。 目标、观点、特征、约束——你的产品愿景开始形成。 确定产品需求使您从模糊的陈述转变为具有完整期限、预算和质量标准的有形任务。

• 让开发人员清楚地了解您的想法。 明确的产品要求可以缩小您想要的移动应用程序与开发人员交付的内容之间的期望差距。

• 获得及时的开发和交付。 借助记录在案的移动应用程序需求，您的开发团队可以更好地了解您的项目、设置优先级并减少返工。

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

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

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

根据 Boehm 的研究，返工可能花费所有软件开发总成本的 40% 到 50%。 返工的主要部分是由需求错误引起的。

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

需求类型

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

• 为什么？ 为什么需要移动应用程序？ 为了帮助人们获得您独特的体验，获得额外的收入来源，作为一项投资——您的目标是什么？
• WHO？ 谁将使用您的应用程序？ 考虑目标用户的痛点、问题、需求和偏好。 用户希望从您的应用中获得什么解决方案？
• 如何？ 您将如何实现预期的业务成果并满足用户的期望？ 想想您的应用程序应该提供的功能。

这些问题的答案构成了移动应用程序开发的三个主要需求级别：业务需求、用户需求和系统需求。

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

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

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

• 开发产品的属性，如性能、可靠性、可用性和可用性。
• 开发过程，描述开发方法、标准、编码语言、时间限制、安全性等。
• 外部环境，考虑您的应用程序与其他系统和硬件组件的连接，是否符合公司政策、政府法规等

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

业务需求

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

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

根据Karl Wiegers在第三版软件需求中提出的愿景和范围文档，我们准备了以下 BRD 结构：

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

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

以下是 Headspace 等冥想应用程序思维导图的简单示例：

请记住，起草业务需求涉及所有项目参与者。 这总是一个共同的努力。

用户要求

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

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

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

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

• 访问级别（访客、普通用户、付费用户、提供商、管理员）
• 他们执行的任务（查找、查看、阅读、选择、购买、分享、评论）
• 他们使用的应用功能（搜索、映射、排序、比较、支付等）
• 访问频率（每天、每月）
• 使用的平台（iOS 或 Android）
• 母语（或其他人口统计数据，如位置、性别、教育和家庭状况。）

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

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

在确定合格的用户代表后，获取他们对两类用户需求的意见。

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

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

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

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

系统要求

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

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

系统要求
功能要求	列出开发人员可以构建的功能，以使用户能够根据您的业务需求完成任务。 为此，请使用现有的思维导图或用户故事。 在定义您的应用程序将做什么之后，为每个功能需求分配一个唯一的名称和编号，以及简短的描述、理由和状态。
子系统要求	从软件和硬件子系统的角度描述您的移动应用程序的要求。 例如，如果您要构建一个健身活动跟踪应用程序，您需要编写可与应用程序同步的可穿戴跟踪器的要求。
商业规则	由于每个企业都受法律、政策和行业标准的约束，因此这些将成为 SRS 要求的明显来源。 以下是需求来源的候选清单： 公司政策 政府规章 行业标准 用户角色和权限等级 If-then 用户行为模型 计算算法，如果有的话
数据要求	在开发移动应用程序时，需要创建、存储、修改、显示、删除、处理和使用海量数据。 要管理数据流，您需要： 概述数据实体交互的逻辑模型 在数据字典中定义实体 指定系统必须如何强制执行数据分析、保留或处理 选择数据报告的类型（电子表格、图表、仪表板等）
质量属性	编写清晰的质量标准可确保开发人员将满足您对最终产品的期望。 您需要考虑对以下方面很重要的质量属性： 您的业​​务和用户，例如可用性、性能和安全性（外部属性） 开发人员，例如效率、可修改性和可移植性（内部属性） 与其他利益相关者讨论哪些属性对您的应用程序的成功至关重要，并确定它们的优先级。 使用适合标准为每个属性写下具体的期望 - 描述您的应用程序必须达到的标准的量化要求。 将质量属性转化为技术规范，并为您的团队编写验收测试，使他们能够检查结果。
外部接口	需要移动应用程序功能需求文档的这一部分来确保您的应用程序能够与用户和外部硬件或软件系统正确通信。 在 SRS 中，您需要写下以下要求： 用户界面。 指定移动应用程序屏幕的设计（字体、图标、配色方案、图像、屏幕大小、布局、分辨率等的标准） 软件接口。 描述您的应用程序与其他软件组件（包括其他应用程序、网站、库、数据库和工具）之间的交互。 硬件接口。 概述每种支持的设备类型、软件和硬件之间的数据和控制交互以及要使用的通信协议。 通讯接口。 在您的移动应用程序的 SRS 中，说明您的应用程序将使用的任何通信功能的要求，包括应用程序内消息、推送通知、电子邮件和网络协议。
约束	记录限制移动应用程序设计、操作和实施的约束条件。 首先，检查您的移动应用需求规范是否符合 Apple App Store 和 Google Play Store 的要求。 此外，指定其他系统约束，例如，由所使用的编程语言或使用第三方 API 或内容的规则。
本地化要求	如果您希望您的应用程序在与其创建时所在的国家、文化和地理位置不同的国家、文化和地理位置中使用，那么您应该设置更改要求： 货币 日期、号码、地址和电话号码格式 语言（包括国家拼写约定、当地方言、方向） 遵守法规和法律的功能 考虑到文化和政治问题的内容 时区 度量衡 其他变量

让我们仔细看看可用于在移动应用程序的软件需求规范中表示系统需求的工具。
电子表格在您打算构建的应用程序功能的行和列中提供传统的演示。 让我们回顾一下我们作为房地产移动应用程序开发文档的一部分起草的功能需求电子表格的片段：

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

开发和管理需求的方法

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

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

移动应用项目的起草要求通常涉及执行四项活动：

1. 引出，或询问用户对新产品的期望，听他们说，看他们做什么
2. 分析或处理用户反馈以了解、分类这些信息并将其与可能的移动应用程序要求相关联
3. 规范收集，包括将模糊的用户输入转换为带有视觉插图的周到、结构化的书面需求文档
4. 验证，这是关于从利益相关者那里确认您创建的需求规范是准确和完整的

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

在Mind Studios ，我们通过采取以下步骤在发现和想法验证阶段定义并同意初始产品要求：

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

• 跟踪需求变化的需求
• 执行影响分析以确定这些变化将为项目开发带来什么
• 跟踪需求维护
• 跟踪每个需求的状态
• 跟踪需求问题
• 维护需求变更的历史记录

一个好的移动应用开发需求文档的特征

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

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

在一个完美的世界中，您在 PRD 中声明的移动应用程序要求应该是：

• 完全的。 例如，每个功能需求都应该包含足够的信息，以便开发人员能够正确实现它。 如果您有一些差距，请将其标记为 TBD（待定）并稍后跟进。
• 正确的。 您和您的开发团队都应该验证您的移动应用程序产品需求文档的正确性。 如果需求符合技术规范、业务规则、行业标准和相关法律，您就可以认为需求是正确的。
• 持续的。 这意味着 PRD 中的任何要求都不应与同一 PRD 中的其他要求相矛盾。
• 可行的。 考虑到已知的员工能力、时间和预算，必须能够在现有的操作环境中实现每个产品需求。 敏捷开发方法和概念原型验证可帮助您评估需求可行性。
• 优先。 每个需求，无论是功能需求还是用户需求，都必须根据要为特定版本实现的重要性进行排序。
• 可修改。 由于需求在开发过程中可能会发生变化，因此您的产品需求文档结构需要灵活。
• 可验证。 产品要求必须是可衡量的和具体的，以便测试人员可以通过测试来检查它们并确定特定要求是否得到了正确实施。
• 明确的。 编写移动应用产品需求文档的主要原因之一是减少沟通不畅。 您需要编写每个需求，以便只能以一种可能的方式对其进行解释。

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

移动应用需求文档模板

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

作为开发初始需求的指导，您可以填写我们的移动应用产品需求模板。 它提供了足够的核心信息来简化和加速开发人员进入您的项目，从而节省您的时间和金钱。

Mind Studios 制作的移动应用产品需求文档简介

完成此简报后，将其通过电子邮件发送给我们，我们的一位经理将及时回复。 This brief will provide a solid basis for creating a detailed mobile app product requirements document with the help of our team.

Have any questions about your mobile app project? 给我们留言。

最后一句话

Even for the smallest projects, it's critical to have a shared understanding of initial requirements. In some cases, ready-made product requirements document templates can help you out. But more often, they're only illustrative. Since no two apps are alike, there's no chance that someone else's PRD will suit your project.

To perfectly meet your specific tasks, you need to create an original mobile app requirements document , which can be a time-consuming and tedious process. The good news is that you can leave it to experts. Especially since they're just one call away.