思维导图( The Mind Map )
又叫心智导图，是表达发散性思维的有效图形思维工具 ，它简单却又很有效，是一种实用性的思维工具。
一般会在需求获取的初期使用，便于产品经理与客户梳理思路。
思维导图工具非常多比较知名的有 MindManager 和 XMind。个人推荐XMind更简洁美观一些。
国内也涌现出不少思维导图工具如 MindMaster、MindLine也是不错的。
统一建模语言 (Unified Modeling Language，UML)
UML是面向对象设计的建模工具，独立于任何具体程序设计语言。
产品经理可以使用UML对系统流程进行建模。
-
功能模型：从用户的角度展示系统的功能，包括用例图。
-
对象模型：采用对象，属性，操作，关联等概念展示系统的结构和基础，包括类别图、对象图。
-
动态模型：展现系统的内部行为。包括序列图，活动图，状态图。
绘制UML模型不必强求工具。如果简单一些的使用word就能画出来
专业的软件有 RationalRose 、MicrosoftVisio、 PowerDesigner等，按照自己的习惯使用即可。
- RationalRose 。 是直接从UML发展而诞生的设计工具，它的出现就是为了对UML建模的支持。对象建模支持得很好，数据库建模较弱。
- MicrosoftVisio。是从绘图工具发展而来，所以画图质量上更好。
- PowerDesigner。更擅长数据库建模。
对于产品经理来说MicrosoftVisio是不错的选择。使用MicrosoftVisio创建业务流程图非常方便，并且可以通过泳道区分用户群体使流程表达更加清晰。
原型设计
软件原型是交互设计师和需求方以及众多干系人沟通的最好方式之一，使很多难以描述的问题变得简单而直观。
同时软件原型也提供了尽早发现逻辑问题的可能性，最大限度的减少了开发完成后的问题修正。
原型设计的工具繁多， Axure 是一个发展较早，功能全面的工具，很多交互设计师在使用。
同时“墨刀”作为国产的原型设计软件也是非常不错的，包含了APP模板设计APP原型也是比较方便的。
JustinMind 作为一款主打APP设计的软件也是不错的。
用户故事（user story）
用户故事主要用于“敏捷开发”团队，“瀑布开发”需要对需求进行完整的描述。
“ 用户故事是敏捷方法的一部分，有助于将重点从撰写需求转移到谈论它们。所有敏捷用户故事都包括一两句话，更重要的是，关于所需功能的一系列对话”
—— Mike Cohn（ Scrum软件开发方法发明的主要贡献者 ）
- 怎么写用户故事
一般情况下用户故事以“ 作为一个<什么角色>，我想要<什么功能>，以便得到<什么好处> “格式进行书写。
示例：作为一个[ 客户 ]，我想要[ 购物车功能 ]，这样我就可以[ 轻松地在线购买商品 ]。
作为一个[ 经理 ]，我想要[ 生成报告功能 ]这样我就可以[ 理解哪些部门需要更多资源 ]。
作为一个[ 客户 ]，我想要[ 在物品到达时收到短信 ]这样我就可以[ 马上去取回 ]。
- 用3C分析用户故事
由于用户故事的描述信息以传统的手写方式写在纸质卡片上，所以Ron Jeffries对这三个方面称为3C：卡片(Card)、对话(Conversation)和确认(Confirmation)。
- 故事地图
用户故事随着逐级细化，会从比较笼统的故事，拆分成许多具体的故事。为了能够掌握需求的全貌和故事之间的关系，我们需要采用故事地图将他们结构化。
传统的需求都是用列表展示，用户故事地图将你的需求列表变成一张二维地图。
用户故事地图有两个原则：从左到右讲故事（主干）按照用户使用的时间顺序进行排列；从上到下拆解故事（细节）越往下粒度越小、优先级越低。
-
橙色标签 —— 用户活动 （User Activities）
用于为用户故事分组，分组会根据不同的业务逻辑而采用不同维度去拆分。其中可以是通过功能模块拆分、也可以是根据不同用户拆分等。
例如上例就分成了组织电子邮件、管理电子邮件、管理日历、管理联系人四个分组。
- 蓝色标签 —— 用户任务（user tasks）
用于编写一级用户故事，这些用户故事用较粗的粒度描述了整个需求的“骨架”。
- 黄色标签 —— 用户故事（User Stories）
用于细化用户任务，将用户任务细化到功能点。
- 横线 —— 发布计划（Releases）
用户故事按照优先级进行划分，相同优先级的故事将组成一个发布版本。发布版本需要考虑到功能的可用性。
- 小便签 —— 进度状态
用于标注每一个用户故事的当前状态。比如说 未完成、进行中、已完成等。这样我们可以看到项目的进展。
用户故事的工具
用户故事并不局限于必须使用工具进行管理，但是实用工具显然可以更便捷。例如Visual Paradigm、leangoo等
需求规格说明书
需求规格说明书通常用于“瀑布模式”的项目需求描述。需求规格说明书涵盖了，项目开发中所有要求的详细描述。开发团队可以通过需求规格说明书了解到所有的项目要求，同时测试团队也会依照此说明验证完成的结果是否符合预期要求。
需求规格说明书通常会根据企业的实际情况，由产品部门、研发部门、测试部门等团队共同制定。
需求规格说明书只要能够清晰传达需求，便不需要拘泥于特定的形式。但是同一个公司或者项目组通常使用相同的模板，以减少沟通成本。
我们也可以参考IEEE制定的国际标准，来设计更加完善的需求规格说明书。
国际标准-系统和软件工程-生命周期过程-需求工程
29148-2018 - ISO/IEC/IEEE International Standard - Systems and software engineering -- Life cycle processes -- Requirements engineering
网址：https://standards.ieee.org/standard/29148-2018.html
软件需求评审
产品经理需要在软件需求的各个阶段适时的安排需求评审工作。需求评审的参与者有可能是各个环节的不同干系人。
需求评审工作主要的目的有
- 获得更多的合理需求
- 完善现有的需求
- 及早发现需求中的冲突和问题
- 获得技术团队的评估
需求评审会议的主旨为“集思广益”不同干系人的集体智慧。
但是需要注意的是一个好的需求评审会议，在会议效率、决策机制以及内容安排上都是需要仔细规划的。
软件功能规模度量（Functional size measurement，FSM）
软件功能规模度量(Functional size measurement，FSM)方法是从用户的角度按功能来表达开发的工作产品，它通过确定功能域的数量来导出软件的规模，它是独立于所采用的技术或工具的。近年来的研究表明，FSM方法是一种有效的度量软件的方法。
需求过程管理
产品经理的需求工作，贯穿于软件开发的整个生命周期是普遍的共识。
对于软件开发过程中需求的有序管理尤为重要，我们可以借助管理软件更高效的管理需求过程。
对于软件项目来说需求工作是其中的一部分，所以软件项目管理软件包含了对于需求过程管理的功能。
比较有名的项目管理软件有Jira、微软Project、禅道、Teambition等
其中作为国产开源敏捷开发项目管理软件“禅道”是非常推荐的。对于预算有限的中小企业其免费功能已经非常丰富，况且又做的非常棒，性价比绝佳。
项目管理软件的选择可以查看capterra（https://www.capterra.com/it-project-management-software/），在这里将提供更多的对比和选择。
参考：https://www.jianshu.com/p/33f9b98ac0e6
变更管理
再努力的前期规划也避免不了日后的软件变更，所以软件变更是一个软件必然要经历的过程。
实施需求变更需要遵循以下原则：
- 建立需求基线。可发过程中每次开发完成或进行变更都要确定基线版本。基线版本确定了项目的一个状态，变更时要按照某一基线版本进行变更。
- 制订变更控制流程。为变更制定统一的流程并将其文档化，每次变更遵循统一的流程，便于标准化管理。
- 成立项目变更委员会（CCB）。委员会应该由几乎所有的相关部门代表组成，这些人将对变更工作作出评估和决策。
- 变更评审。所有的变更都应该由委员会进行评审，以便防止造成资源的浪费。
- 仔细梳理关联功能。变更工作一个重要的难点在于，表面上更改了一个小问题，但是可能在非常隐蔽的位置影响了其他功能。所以每次变更都要认真仔细的梳理流程，减少变更后发生问题的几率。
- 结构化变更文档。变更文档需要是可追溯的，一个良好的文档结构便于日后快速的查找到历史变更。
有向无环图（ Directed acyclic graph ，DAG）
有向无环图指的是一个无回路的有向图。 在图论中，如果一个有向图无法从某个顶点出发经过若干条边回到该点，则这个图是一个有向无环图（DAG图）。
因为有向图中一个点经过两种路线到达另一个点未必形成环，因此有向无环图未必能转化成树，但任何有向树均为有向无环图。
我们可以使用有向无环图来梳理需求和需求变更间的关系。
需求可追溯矩阵（ Requirement Traceability Matrix，RTM）
需求可追溯性矩阵（RTM）是一个通过测试用例映射，来跟踪用户需求的文档。 在软件生命周期结束时这个文档记录了，客户提出的所有需求和需求可追溯性。 需求可追溯性矩阵的主要目的是验证是否通过测试用例覆盖了所有需求， 以便在软件测试期间不遗漏任何功能。
需求可追溯性矩阵在很多时候都没有被有效的使用，究其原因在于很多中小型项目组对于急时维护文档而感到疲惫。
也就是说需求可追溯性矩阵能够被急时的维护是非常重要的，如果做不到文档的真实和有效性，那么不如不要投入精力去使用它。
垂直可追溯性确定了项目的来源（如，用户需求），项目团队将这些内容进行分解和有层次的组织，最终用户获得预期的结果。 如果对需求进行了很好的管理，则可以建立从源需求到产品需求以及产品需求回到其源的可追溯性。 这种双向可追溯性有助于确定所有源需求都已得到完全解决，所有产品级别的需求都可以追溯到有效的源。
水平可追溯性可确定工作组或产品组件之间相关项目之间的关系，以避免潜在的冲突。 它使项目能够在集成测试之前预测潜在问题 ，以便及时解决它们。
需求追溯矩阵表包括以下内容：
- 用户需求。用户需求编号、用户需求标题、用户需求标识（新增、修改）。
- 产品需求。需求列表编号、需求列表标题、需求变更标识（新增、修改）。
- 变更。需求变更编号、需求变更标识。
- 设计。概要设计编号、概要设计标识、详细设计编号、详细设计标识。
- 测试用例。测试用例编号、测试用例标识。（包括单元测试、集成测试、系统测试）
- 代码。相关类和方法。
需求追溯矩阵可以使用 EXCEL 来维护，也可以使用 DOORS 之类的软件工具进行维护。
参考：https://www.jianshu.com/p/6d7a14badd6c
验收测试
虽然软件的测试工作有专业测试人员完成，但是一个合格的产品经理在软件上线前还是需要进行验收测试的。
产品经理验收测试的关注点与专业的测试人员是不同的。产品经理作为最熟悉软件业务的人，在验收测试阶段主要需要验证软件的业务流程是否达到预期要求。并且及时发现隐藏比较深的业务漏洞，以便在上线前及时修正。
来源：oschina
链接：https://my.oschina.net/u/3452433/blog/4320461