课程目录
1.
2.
3.
4.
5.
6.
7. < —
8. - -
9.
—
有时候，似乎开发人员的任务显而易见！但是，在解决问题时不要过分依赖常识。对于任何甚至最简单的任务，都有可能出现差异，因为人们倾向于生活在自己幻想的世界中。例如，在古巴共和国，人们认为墙壁应该光亮而杂色，即使客户要求将墙壁涂成白色，工人也可以添加色斑，因为“这样更美丽”。发展也是如此。
这样的要求文件有助于克服“误会”。需求的存在使您可以对产品中需要完成的功能，功能到底是什么有相同的想法。
如何建立需求
在制定开发需求时，您需要了解我们正在为哪个用户开发产品。这是User Persona派上用场的地方（我们已经在这里谈论过它们了）。用户角色是系统中的所谓参与者，为每个参与者定义一组规则和功能。
例如，可以在网络论坛应用程序中定义以下参与者：
- 管理员可以执行所有操作，实际上可以执行所有操作-包括将角色（人员）分配给其他用户。
- 普通用户只能留言。
- 主持人可以留言，删除其他人的留言，禁止普通用户。
对于我们在课程中定期回想的出租车呼叫应用程序，人员可以是乘客，出租车司机和操作员。
为了制定适当的要求，您需要草拟一个称为功能描述的文档。为此，您需要回答以下问题：
- 做什么的？目的是什么？有哪些商业利益？
- 为什么？有什么风险？如果不这样做，我们会失去什么？如果我们这样做会怎样？
- 什么？我们要解决什么问题？为了谁？
- 怎么样？功能需求和用例（操作顺序）。
还必须提供主题领域的词汇表。对于特定的首字母缩略词尤其如此。例如，开发人员可能不知道钢铁行业或烹饪的所有过程名称和详细信息。
最后，文档需要做一个“批准”部分，一方面，该功能的客户（利益相关者，客户，产品经理）同意该描述与他们想要的产品相匹配。另一方面，开发人员（团队负责人，架构师）将确认需求中的任务描述清晰完整。因此，开发过程中的所有参与者都必须说：“是的，我们了解文档，现在可以完成了”
辅助指标
处理需求时，辅助指标有助于实现任务的准确执行，并减少检查合规性所花费的时间。
- “完成”的定义是有关如何知道某个功能是否正常工作的简短描述。
- 非功能性需求-技术参数的需求，例如UI响应能力，后端负载，CPU和RAM限制。这是非常重要的一点，因为如果您不满足要求，那么您可以获得一个怪物-内置的photoshop，而不仅仅是选择汽车的颜色。
- 安全要求-加密，个人数据存储等
- 角落案例-测试边缘案例。如果产品价格为0，会怎样？一个人可以同时订购多少辆出租车？
- — , . , , , , — Visa, MasterCard, , .
- . , , , , . , , . , .
- . , “ ”, “ ”.
功能和非功能需求，用例
让我们稍微介绍一下功能和非功能需求。
功能需求说明了需要做什么，它们列出了应用程序的动作，作为对Actor动作的反应。这些要求在列出的使用方案中实现。
非功能性需求捕获了解决方案必须保持有效的条件或解决方案必须具备的质量。非功能性需求的最常见示例是：
- 可扩展性
- 可靠性，最少的停机时间，
- 支持方法。
用例也用于描述需求。这是文档的主要元素，我们在生成功能请求时会准备这些元素。脚本应提供用户可以对您的应用程序执行的操作的完整的分步流程。
用户脚本通常包含以下部分：
部分：上下文
回答问题：哪个组件？什么情况
示例：用户未被授权。
科：演员
回答问题：什么人？
示例：普通用户。
部分：前提条件
回答问题：有哪些功能？
示例：有邀请获得VIP身份的邀请。
部分：目的
回答问题：用户打算做什么/得到什么？
示例：登录。
部分：主要方案
回答问题：需要采取什么措施才能获得结果？
示例：输入您的用户名和密码，然后按“输入”按钮。
部分：错误的脚本
回答问题：可能出什么问题，错误列表，包括针对用户的错误消息文本。
示例：未按下按钮，语言未更改，无法通过https协议建立连接，依此类推……
部分：布局
回答问题：UI设计的可能布局或原型。
示例：在Figma或Sketch中绘制。
以简化形式，自定义脚本可能如下所示：
揭露
. ( e-mail) ( ). , , : « » « . »
如何阅读功能描述？
每个类别的用户都可以根据需求为自己收集有用的信息。因此，请务必记住，需求将由不同的人阅读：
- 开发人员-了解他们为什么需要此功能，解决什么问题很重要。为了避免以后浪费时间进行修复，开发人员需要提供所有方案的完整列表，并注意Corner案例。如果您及时通知开发人员我们以后会增加的内容（例如，使用MIR卡付款），那么他将能够在架构级别上预见这种可能性。因此，通过避免返工可以显着降低成本。
- , QA — , . Corner Cases. , — , .. ( , , ) . , . .
- DevOps Datacenter Operations— , , , . DevOps , , , .
- — , , . , , .
如果您编写开发要求，请确保问自己一个问题-用户是谁，他在做什么（或可以做什么），在什么条件下工作。创建他的行为图，将有助于描述需求的各个方面。
在起草文件时，您需要尽可能地简短，并且不要留下难以理解的地方。无论如何，需求将跨越多个页面。它需要许多人阅读，并且必须可读。
遵循一个简单的规则：从主要内容开始，然后再添加详细信息。此外，您需要获得质量检查，开发人员，DevOps和其他利益相关者的反馈。与利益相关者沟通后，功能描述很可能会获得新的细节。
尝试考虑非显而易见的情况。建议立即确定您的应用程序在紧急情况下应采取的措施。考虑一下哪些外部组件正在影响您的功能。当一切准备就绪后，再问一个问题：“除了自定义脚本中描述的步骤之外，您还可以测试什么？”
结论
在下一篇文章中，我们将讨论新产品的商业计划和定价。
同时，在评论中，从经理和执行者的角度分享您处理需求的经验。告诉我们，您的实践中是否有一个示例，说明功能正常的客户想要一件东西，但是由于误解，最终结果却完全不同？
→可在YouTube讲座中获得课程所有讲座的录像，该
讲座的路线图和开发要求如下：