如何将业务需求转化成软件需求(下)

如何将业务需求转化成软件需求(下)

上一篇我们分享到当接到业务需求时，我们需要先定义需求、明确范围、明确出上下文关系并划分出主题域，然后将相关的主题域内容用业务事件、报表列表的方式展示。

接下来我们继续拆解如何将业务需求转化成软件功能，这一次分享需求获取与分析建模。

需求获取对获取人员的能力要求很高，需要访谈人沟通能力强、善于把握主动权、善于聚焦话题。其中用的方法有很多，使用的时机也不尽相同，需要获取人员拿到方法后灵活使用。

大家根据不同项目采用适合的需求或许方法，无论选择哪一种方法。需要注意的是事先做好计划。以用户访谈为例需要计划访谈时间、预约访谈人员、计划访谈问题。

如果说需求获取是拿到了第一手的原滋原味的材料，那么需求分析就是加工成美食的过程。需求分析实际上是业务分析，通过一种业务导向将零散的需求串连起来，形成一个体系完整、内容清晰的框架，这里我理解的就是业务框架或是叫业务架构，以指导后续的设计与开发。

需求分析三个关键动作要领：分解、提炼、消除疑问或矛盾点

业务流程为主线索的分解

程序结构为主线索的分解

提炼是在分解的基础上将每个业务事件中的类进行提炼，抽取公共的部分，建立针对整个系统的全局领域模型。

在分解与提炼的过程中，我们会发现有些需求是相互矛盾、冲突的，这样就可以快速的找到相应的人员，进一步的需求沟通确认消除发现的问题。这个分析出来需求的过程是需要多次反复进行的，层层剥离分析，直至发现各个层级的问题。

接下来就是需求建模，建模是需求分析的手段，这就是将业务需求转成产品功能的方法，建模的目的是帮助大家按照实际情况或需要的对系统进行可视化，提供一种详细说明系统的结构或行为的方法。

下面以体检者申请体验为例：

业务流程分析：

业务实体分析：

用例图：

抽象体检业务子系统领域模型：

上述分析过程可以总结如下演进过程，产品经理的核心是从需求获取、业务建模。如何条件允许和开发技术人员一起把领域模型梳理出来，后面的工作就分开一部分是接着开发人员做设计，产品人员做软件的整体原型设计。

本期（总计第21篇）分享完毕！

用心体会经历、用心总结心得，敬请期待下一期。