产品经理像专业人员一样执行“需求分析”!

产品经理需求分析

产品经理像专业人员一样执行“需求分析”!

需求分析是业务风险的子集。 它是为进行需求分析而执行的一组有组织的活动和任务 。 举一个简单的例子,有时系统的需求太大,无法整体处理,因此将它们划分为子系统。 这些子系统需要定义,集成和记录,所有这些成为需求分析工作的一部分。让我们对需求分析过程中的所有操作进行汇总:· 理解需求 –了解,扩展需求,并向其中添加更多详细信息。· 模型需求 –需求通过数据和流程建模等技术进行建模。· 验证和验证需求 –根据需求的可行性和适合性对需求进行验证和确认。· 管理需求 –需求在不断发展,应该对其进行更改和更正。通过详细说明,我们将对上述每个元素有更多的了解。

1.理解要求

一旦收集了最初的需求集,就可能无法正确理解它们,并且可能会缺少一些详细信息/方案。 我们调查了本部分中所有遗漏的需求,并通过会议和不同的启发技术收集了所有必需的数据。同样,需求仅在此部分的不同部分下分类。 他们是:· 功能要求 –这些要求定义了系统应“做什么”。 这些要求指定了系统预期提供的结果及其行为。 例如,一个过程的输出。· 非功能性需求 –定义了系统的“状态”。 这些要求指定了系统的质量和属性。 例如,可用性和可扩展性。· 性能要求 –定义系统应有多好的性能的要求被认为是可以接受的。 它包括质量,吞吐量和准备情况。· 设计要求 –这些要求是针对更多技术解决方案的,最初定义了系统的设计和建造方式。· 其他包括结构要求和行为要求。此外,如果要在有限的时间范围和资源范围内满足大量要求,则应决定首先开发哪些功能。 在需求之间取得平衡的行为也仅在“理解需求”部分中发生。 它涉及发现在满足要求时可能遇到的挑战,并确定优先级的基础归零。

2.型号要求

需求中包含许多信息,并且此信息与解决方案的其他各个模块高度相关。 同样,有许多需求(业务,技术等)的接收者具有不同的理解水平。 因此,应该将需求建模为各种视图,以服务这些不同的受众。 建模的目的是将复杂的信息描绘成一种简单的方式,以易于理解。这些模型有助于以正确的方式开发解决方案,并有助于交流。 使用文本,图表,图形和矩阵对需求进行建模。 让我们看一下实现需求建模的不同技术类型:· 流程建模 –一项任务可能涉及具有不同角色,属于不同部门的不同人员之间的交互。 流程模型描述了这种关系与序列中表示的事件流的关系。· 数据建模 –每个项目/产品都涉及数据,并且数据建模通过提供解决方案中涉及的数据的定义,结构和格式来帮助开发解决方案。 两种广泛使用的数据模型是实体关系图(ERD)和类图,它们分别用于关系数据库和面向对象的开发。· 域建模 –以实体,实体的属性以及实体之间存在的关系的形式对完整解决方案进行建模的过程。 领域模型是一种创新的方式,可以查看解决方案的范围并与项目的其他涉众讨论/讨论。· 范围建模 –为了避免任何范围蔓延,标记项目范围的边界非常重要,而范围建模正是这样做的。 范围模型,定义并限制项目范围。· 数据流程图(DFD) – DFD只是通过系统的数据“流”的图形表示。 它描述了如何从系统输入,存储,处理和输出数据。· 顺序图 –它们有时称为事件图,用于通过对象和类描述场景中功能的顺序。BA使用以上建模技术中的任何一种或组合使用来创建要开发的解决方案的不同表示/视图。 这些表述由主要利益相关者进行讨论并达成共识,并成为项目文档的一部分。

3.验证和确认需求

它已经看到强调,业务分析师收集的要求应该是正确且明确的。 此外,它们必须具有SMART的品质,即特定 , 可测量 , 可实现 , 相关和可测试 。当要验证需求时,BA会确保对包含需求的文档进行彻底的检查,并且是最新的,并以必需的格式包含所有必要的信息。需求确认包括确保需求有助于实现业务需求/业务案例的过程。 这是一个持续不断的过程,它可以验证需求始终与所提出的解决方案保持同步。 通过涉及业务分析师,项目经理和其他关键利益相关者的便捷演练来验证需求。 这些演练会生成已接受和批准的需求文档,它们将成为项目的基础文档。

4.管理需求

管理需求是记录,跟踪,协作,交流和归档解决方案需求的过程。 需求管理是一项持续的活动,横跨项目的整个生命周期。 让我们看看这些方面中的每一个-· 文档 –需求被正确记录在不同的文档类型中,例如用例和用户案例。 这些文档中的每一个都遵循由执行组织决定的预定模板。· 跟踪 –需求是渐进的文档,并且随着业务需求的变化而不断变化。 这些文档应能够通过版本控制反映这些更改。 使用元数据对版本进行版本控制,例如版本日期,版本依据和版本详细信息。 这种跟踪将使项目涉众可以随时使用最新文档。· 协作 –需求文档与项目的不同利益相关者共享,有时它涉及多个人同时访问文档。 有时,使用文档协作软件可以轻松有效地进行协作。· 沟通 –需要将需求告知项目团队,发起人和其他利益相关者,这在需求变更时更为重要。 沟通应迅速,准确并与相关人员进行沟通。· 变更管理 –在需求变更或修改的情况下,变更文件,其影响,负责变更的利益相关者和变更批准委员会应得到适当的文件记录。 所有现有项目文档都需要根据新更改进行修改。· 存档 –所有技术,功能和业务要求均应正确索引并存档,以供将来的项目使用。

更多干货可以关注微信公众号:李老板产品派

0条评论 添加新讨论

登录后参与讨论
Ctrl+Enter 发表