从基本需求定义开始，数字需求可以分为两类：功能和非功能。
出于本讨论的目的，我们将重点关注我们通常在数字产品和服务中看到的这两类要求。当然，还有其他类型，例如法律和技术要求，并且根据具体情况，负责处理需求文档的人员可能需要额外的技术写作，信息映射等方面的培训。
对于数字参与，功能需求与产品的功能相关：功能，可用性，功能和与产品预期目的相关的操作。通常，功能需求在功能需求文档（FRD）中明确引用。虽然工作说明书（SOW）概述了所需产品的高级目标和要求，但FRD提供了对这些要求的更深入的详细说明，这些要求在项目启动后立即收集，直到项目开始生产。
附注：要求不限于生产前的时间窗口：更改订单文档，保修文档等是整个项目甚至项目之外的持续需求文档的有用形式！只要您与客户合作，文档就会不断发展并不断发展。
根据项目的规模和范围，您可能决定SOW和FRD之间的里程碑（因为此时间范围可能跨越几个月）。在这种情况下，一些团队创建业务需求文档（BRD），为所有各方提供正式的中途签收 - 期望检查点。这为项目经理提供了一个机会，让他们确认团队正朝着正确的方向前进，然后才能通过可交付成果走得太远。
非功能性要求包括与产品功能无关的任何内容：性能，稳定性，安全性和技术规范，仅列举数字行业中的几种非功能性要求。
功能性和非功能性需求文档都以自己的方式起到同样的作用。它们手拉手存在; 一个直接受另一个影响。
即便如此，并非所有非功能性要求都直接对应于功能要求。例如，服务器设置和配置是一种非功能性要求，它会影响整个站点的稳定性，而不会与任何单一的功能要求直接建立1：1的关系。
以下是功能和非功能需求的几个示例，以及它们之间的关系：
虽然它是2018年，网站应该有SSL证书，但如果网站上实施了支付处理功能，这一点尤为重要。这是一个非功能性需求（SSL证书，影响安全性的实现元素）的一个示例，它直接影响功能需求（支付，影响可用性的实现元素）。
这是另一个例子：
根据资源登录页面的功能，用户可以访问PDF，图表，课件或电子表格等资源。此功能是页面的功能和操作。这是一项功能要求。
另一方面，管理面板文件格式规范是非功能性要求; 它们是与管理功能相关的技术规范。它们不会影响最终用户的可用性。是的，这些规范确实会影响管理用户的可用性，但它并不直接定义产品的功能对最终用户的影响。这是一项非功能性要求。
需求管理很重要，主要有两个原因：
除了概述他们可以期待的内容之外，需求管理计划的一部分应该概述不期望的内容。包括“假设”和/或“排除”部分是消除可怕的客户想象风险的明智方法。
让我们看一个示例，展示需求收集如何作为参考点和管理期望的蓝图：
请记住：客户期望与实际数字产品之间的差距越小，客户对最终结果的满意度就越高。
您的需求管理质量与您作为数字项目经理的能力直接相关，以减少客户期望的“灰色区域”。
绝大多数情况下，如果客户保留预算，客户将接受您的限制范围蔓延 ; 如果你充分教育客户为什么要解决（或不解决）某个功能，然后在需求中记录该方法背后的逻辑，那么你的客户就更有可能进行协作（他们通常喜欢感情参与，不是吗？ ？！）。他们更有可能提供他们的批准，并且当他们进行用户验收测试（UAT）时，他们将更快地了解团队解决方案背后的“原因”。
虽然需求收集应该在订单开始时以及整个项目生命周期中开始，但是完整网站构建之后的大部分需求文档应该在发现之后（内容策略，站点映射，线框，设计）和开发之前落实。开始收集和记录项目要求永远不会太早。事实上，从昨天开始。
开始收集和记录项目要求永远不会太早。事实上，从昨天开始。
以下是有关如何收集需求，完成需求收集过程的步骤。这些步骤将帮助您通过团队协作，检查和平衡以及客户培训来最终确定需求文档。
在您参加的每次会议中 - 无论是项目团队的内部会议还是客户的外部会议 - 始终记笔记。永远不要假设其他人正在服用它们。机会是......他们不是。
数字项目经理不是秘书，但我们期望我们捕获行动项目，澄清需求，进行额外研究/讨论的机会以及会议中讨论的任何其他重要信息。目前，可能很容易假设所讨论的所有内容都会被记住，但是3个月和15个会议之后，您的团队和您的客户将会感谢您记录这些讨论的内容。
阅读更多关于优秀笔记策略的信息，或查看我在此处获取需求说明的一些建议程序：
不要将设计和样式决定留给我们：尽可能提供创意要求。如果您的时间表和预算允许，创意指导对开发人员来说非常宝贵。虽然你可能会发现那些兼任设计师的罕见的独角兽开发者，但你经常会发现开发人员最擅长开发; 不要让他们完成设计任务。
至少，提供样式指南 - 即使样式指南像字体和品牌颜色一样裸露。理想情况下，您将拥有适用于所有页面类型的移动和桌面的线框和完整用户界面设计。
收集完毕后，将所有广告素材资源上传到共享空间，以获得完整的团队访问权限和可见性。确保您将这些设计的最终版本保存在一个地方，与任何旧版本分开，因此您的团队绝对确定他们正在引用最终的广告素材资源。
当创意最终确定并由客户正式批准时，为项目团队安排内部交接会议是很有价值的; 这为您的创意团队成员提供了一个机会，可以顺利地将他们的工作交给开发团队成员。它还允许讨论提出问题，澄清澄清需求，并降低开发人员假设的风险 - 这是一个危险的游戏。您的“创意团队”可能不仅限于您的UX / UI设计师; 这可能还包括为用户旅程说话的数字策略师，或者讨论站点地图的内容架构师。包括迄今为止为可交付成果做出贡献的每个人，这将不可避免地带来未来的开发，生产和实施。
一旦您将可交付成果从创意转移到开发，就可以在所有页面类型中注释您的页面元素。这可以包括静态与轮播英雄图像，网络表单中的下拉列表与文本字段，下拉列表与幻灯片，弹出模式与新页面加载以及每种页面类型上的任何其他功能。
只有在绝对最终的页面上才会注释。没有什么比仅仅因为一个分页子弹阴影被删除而重新注释一个包含35个元素的页面更糟糕的事情（好吧 - 有更糟糕的事情，但你得到了我的观点）。
每个页面元素都需要注释。使用Invision或Skitch等工具注释页面设计。
通常，我首先注释移动页面设计，然后我注释相应的桌面设计 - 仅限该页面的功能与移动体验到桌面体验的不同。为什么从移动开始？在数字行业中，在制作数字解决方案时始终牢记“移动优先”的心态是最有益的。话虽如此，您可能在工业或机械产品领域拥有一个客户，其用户通过仓库桌面访问他们的平台，无法通过移动设备访问。在这种情况下，您应该首先容纳和注释桌面页面设计。
我的观点是：无论是移动设备，平板电脑，桌面设备，肖像设备，风景设备，还有什么......首先注明页面设计的格式或类型是最有意义的。然后，根据需要调整每页的剩余设计。我在我的需求文档中包含以下注释以拒绝此意图：
注释广告素材后，将图片加载到文档中。以最有意义的顺序执行此操作。如果存在用户旅程，则最有利的是将其用作组织注释设计的顺序的指导。例如：
如果您没有利用的用户旅程，那么以对您的客户有意义的方式组织注释页面设计。对于在您的需求文档中显示的第一个设计，主页始终是一个安全的选择 - 可能是您的客户在此时最熟悉的页面设计。请记住：在订婚的这一点上，您在需求文档中包含的任何内容都不应该让您的客户感到惊讶。这不是向他们展示任何新东西的工具; 本文档正式确定了您的客户已经讨论，决定和（至少轻柔地）批准的内容。
在深入了解文档时，请记住：首先阅读需求文档将是最困难的。为什么？因为您没有可以利用的先前文档（也称为COPY-PASTE）。亲爱的DPM朋友，幸运的是，本文包含一个需求文档模板，作为您的基础。
如此模板中所示，我将需求文档组织为四个部分：
完成需求文档的初稿后，请先煮一杯啤酒。或根啤酒。好好享受。但只有一个。还有工作要做。而且我保证：前期工作是值得的。
在需求收集过程的这一部分中，您将与项目团队安排另一次内部会议，以便一起审查您的需求文档。这是最终的内部检查和平衡，以确保您了解实施。这是必要的。因为猜什么？作为DPM，您可以管理客户对实施的期望。您对它的理解对项目的成功和客户的快乐至关重要。
如果可能，让团队在会议之前审核您的需求文档，以便他们能够准备好他们的问题和/或反馈。使用会议讨论任何问题，并反馈有关要求。确定理解方面的差距和验证需求文档的一致性。
作为内部审核阶段的一部分，您需要根据内部讨论对文档进行必要的修订。最后，将修订后的需求文档重新发送给团队，以获得最后的祝福。
一旦内部项目团队提供了对需求文档的最终批准，请将文档另存为PDF（这里有关于PDF的一些信息以及如何编辑PDF）以确保在下一步保持最终状态：任务构建。
向开发团队提供需求文档的PDF版本。理想情况下，您的开发人员或开发负责人将执行构建的任务构建。虽然有些组织可能在DPM构建所有任务的过程中运行，但我更愿意让开发人员构建自己的任务; 他们花费的少数时间是值得的。这允许开发人员以适合其开发方法的方式构建任务。
在构建开发任务时，您仍然可以为团队提供有用的指导。以下是网站构建的一些示例指南：
任务扩建后，您将能够获得最后一小时的估算。例如，如果开发人员以小时估计值计算所有任务，并且他们的小时总数为150，那么...
此时，您将该投影与先前已传达给客户的时间线进行比较，并根据需要进行相应管理。
此时，你有：
是时候向客户提供需求文档了。将其作为PDF提供，以确保不进行编辑。包括立即请求会议的消息，以便一起阅读本文档。这（1）举例说明了您的投资以确保客户对数字解决方案的理解，以及（2）作为DPM的保险，能够说“我告诉过你”（但更有说服力）在这个过程中，蠕变不可避免地会变得丑陋。
教育你的客户。走过这些珍贵的文档，你们为他们精心拼凑起来。您可能拥有实施数字解决方案的丰富历史的客户。但我敢打赌，往往不是，你没有，他们没有。
虽然您的客户可能会抄袭文档，但您可能会对能够随身携带文档的兴趣和欣赏感到惊讶。请记住：他们是他们业务的专家。您是您提供的数字解决方案的专家。他们正在为您提供此解决方案。教育和授权您的客户。他们（可能）应得的。开始谈话，确保他们明白这是时候问他们可能有什么问题，请求澄清，毫无疑问是一个愚蠢的问题。他们会很感激。最糟糕的情况：他们拒绝了散步的要求。至少你可以说你提供了。我会告诉你：我没有一个客户拒绝这个请求。
一旦客户确认了他们对需求文档的理解（他们是否决定与您一起讨论），最后是时候获得正式批准了。我强烈建议在开始任何开发之前收到此要求文档的签名。它似乎是一个给定的 - 但这种依赖性经常被滥用。尽你所能坚持下去。
将签名和批准的需求文档发送给您的团队并保存在共享空间中，因此可以正式指示开发可能已开始。
教育和授权您的客户。他们（可能）应得的。
下面是一个不那么大的要求的例子 - 一个严重缺乏需求管理的例子。这是一个真正的要求，包含在真实客户签署的自定义电子商务网站构建的文档中。
当前[未完成的ECOMMERCE平台版本]网站上存在的所有扩展将在新的[未完成的ECOMMERCE平台版本]网站上实施和运行。
哦，我的兰达。含糊不清。
虽然我不打算重写上述句子的多页技术和功能需求文档，但我将概述几个问题以打破要求并挑战作者进一步澄清和记录这究竟是什么意思。
虽然您的团队可能非常了解上述所有问题的答案，但了解并不足够。必须彻底记录这些知识。DPM必须管理问这些问题并戳出这些漏洞，以确保填补这些漏洞。
专注企业应用的研发与服务，提供专业解决方案和技术开发
