需求收集思维导图：分析师免费模板
需求收集思维导图模板，在一张可编辑画布上整理干系人、业务需求、用户需求、功能与非功能需求以及约束条件。
需求收集思维导图把谁想要什么、为什么、在哪些限制下，集中在一页上，让干系人之间的缺口和冲突在设计开始之前就显现出来。
需求收集思维导图：分析师免费模板
The interactive MindMap canvas for this explanation — every lane, row and arrow above is a real QueryChart diagram you can open and edit.
如何阅读这张思维导图
- 先看“干系人”和“业务需求”，了解涉及哪些人以及为什么。“用户需求”从用户角度描述需求，“功能需求”和“非功能需求”则把它转化为系统必须做什么以及做到什么程度。
- 虚线箭头标示推理过程。例如，“优先级”下的某项能力由“目标成果”中的成功衡量标准来论证，而“安全与隐私”中的安全需求可能与“技术限制”中的技术限制相冲突。
干系人
“干系人”是导图的起点，因为每一条需求背后都有人。在“发起人”下列出出资的人，在“最终用户”下列出使用成果的人，在“审批与支持人员”下列出必须批准或支持的人。
要访谈“最终用户”中的每一个人，而不只是他们的主管。常见的错误是依据发起人对某项工作的描述来写需求，而他们早已不再做这项工作。
业务需求
“业务需求”说明项目为何存在。“要解决的问题”是问题或机会，“目标成果”是算作成功的成果，“成功衡量标准”是证明它的衡量标准。
导图上其他位置的每一条需求都应能追溯到这里的某项内容。如果追溯不到，就问清它服务于什么需求，或者将其删除。
用户需求
“用户需求”记录人们需要完成的事。把“待完成的任务”写成站在用户角度的任务，并在“当前痛点”下记录当前工作方式的痛点。
“使用情境”记录用户的工作情境，例如在手机上、在嘈杂的地方或在时间压力下。这些细节对设计的影响往往比任务本身更大。
功能需求
“功能需求”列出系统必须做什么。“核心能力”是主要能力，“业务规则”是必须遵循的规则，“接口”是与其他系统或团队的接口。
每一条都要写成可以测试的形式，例如：系统在一分钟内发送确认。可以把“可测试的表述”作为细节写法的范例。
非功能需求
“非功能需求”涵盖系统必须运行得多好。“性能”设定速度与容量，“安全与隐私”涵盖安全与隐私，“易用性与可访问性”涵盖易用性与无障碍。
这些是人们忘记询问、上线后又为之争论的需求。尽量为每一项给出数字或标准。
约束条件
“约束条件”列出方案不能逾越的限制。“预算与时间”是预算和时间，“技术限制”是现有系统等技术限制，“法律与政策”是法律或政策义务。
尽早用“技术限制”核对每一条需求。与硬性约束冲突的需求，应由发起人决定，而不是交给团队去做。
各分支如何相互关联
需求自上而下流动。“业务需求”给出理由，“用户需求”给出用户视角，“功能需求”和“非功能需求”是由它们推导出的需求。在前三个分支中找不到来源的需求，可以考虑删除。
“约束条件”则自下而上反推。某项约束可能让一个需求变得负担不起，这会让你回到“业务需求”，问是否可以接受较小的成果，并回到“干系人”与相关人员达成一致。
思维导图的边界与其他图表的开始
用思维导图来收集和组织。要描述工作目前如何流转、应当如何流转，可以画流程图；当需求取决于团队之间的交接时，使用泳道图。
组织架构图可以记录干系人和审批结构；一旦需求变成有排期的交付，就由甘特图接手。
Key relationships and takeaways
- 每一条需求都应能追溯到一项业务需求和一位干系人。
- 用户需求写成任务，功能需求写成可测试的行为。
- 非功能需求是早期草稿中最常缺失的部分。
- 约束由人来决定，因此也会出现在干系人之下。
- 没有优先级的需求，会被当作与其他所有需求同样紧急。
When to use this visual
- 准备干系人访谈，并把答案记录在共享的导图上。
- 在签字确认之前，检查需求文档草稿是否缺少某些类别。
- 为小型内部工具划定范围，这类场景下完整的规格说明有些过度。
运作方式
找出相关的人
重命名“项目需求”，然后在“干系人”下列出干系人，并标出你还没有沟通过的人。先访谈，再填写其他分支。
按所听到的记录需求
把原因放在“业务需求”下，用户任务放在“用户需求”下，系统行为放在“功能需求”下。在每个节点中注明来源，以便日后回头核对。
检查限制与冲突
用“非功能需求”和“约束条件”核对每一条需求，在冲突之处画上连接，并把尚未解决的冲突交给“干系人”中列出的干系人。
常见问题
功能需求和非功能需求有什么区别？
功能需求说明系统做什么，例如创建发票或发送提醒。非功能需求说明系统要做到什么程度：速度、安全、可用性、可访问性。两者都需要，而非功能需求如果不直接去问，通常要到很晚才会被发现。
为什么从干系人而不是功能开始？
因为每一条需求都有一个能解释它、必要时能修改它的负责人。从功能开始，得到的是一份没人能为之辩护或排序的清单。从人开始，则能告诉你该访谈谁，以及两条需求冲突时必须由谁来达成一致。
导图上的需求应该写到多详细？
详细到能够辨认和讨论，简短到能够快速浏览。用想法写简短的表述，用备注写来源或测试条件。当某个分支变得拥挤时，把它转入需求规格说明或用户故事待办清单。
干系人可以直接评审这张导图吗？
可以。把图表分享给评审人，让他们对具体需求发表评论，并利用版本历史记录每轮评审之间的变化。这比来回发送邮件文档更可靠地完成签字确认。
从这份需求导图开始
把模板作为你自己的画布打开，为项目命名，并先列出需要沟通的干系人。