那么，产品设计，就从需求分析开始吧。
这本书的内容融合了很多关于如何提问题的思考，如何沟通的思考，如何进行事务分析的思考，如何运用软件工程的知识，把需求分析的各个层面的内容都讲的相对比较深入，内容也很全。所以我不想放过这本书，作为需求分析的重要学习资料。
但是，本书的内容体系庞大，我自己是在理解和消化上花费了比较长的时间，所以我想，试着重新整理书本的内容，重新组织，找到关于“需求分析是什么，如何进行需求分析，以及需求分析要做些什么”，这些问题，相关的答案。
先从一个案例开始。
有一个医院希望建设一个医院信息管理系统，以提高医院的信息化管理水平。
这个信息系统包含体检模块。这里忽略业务目标的推导，直接输出关于体检业务的用户需求分析结果。
需求分析过程
用户需求分析的结果，不涉及任何软件系统的描述。它告诉我们，在业务环境下，进行业务操作，用户需要做什么。
在用户需求分析之后，我们进行业务需求建模，完成了需求建模工作之后，软件需求将以如下的模型，和从左到右的模型构建过程体现出来：
软件需求分析建模过程
软件需求模型模型重点在于把需求的“意义”量化，所以形式我认为不是最重要的。我们看图，它由一个一个带有业务意义的分析模型出现，这些分析模型的关系，就好像俄罗斯套娃一样，一层一层地剥开，直到露出了系统需求的真面目。
这个过程我们先不讲，但是软件需求分析的最终，会告诉我们，人和系统之间的交互过程是怎样的，在这个交互过程中，系统将输出什么“价值”给到人类。而这个过程，系统始终是一个黑盒子，没有任何系统开发过程的梳理。
从上面的案例可以看到，需求分析的过程就是梳理业务目标，输出用户需求，转化为软件需求的过程。我们也将这个过程抽象为：提出问题（梳理业务目标），寻找答案（输出用户需求），输出结果（转化为软件需求）的过程。
需求分析过程三步骤
一、需求定义阶段，梳理业务目标
需求定义过程
需求定义核心输出两类内容：
- 业务目标：
业务目标，就是提出企业/组织需要通过软件系统解决的问题，并考虑问题解决之后带来的影响，同时量化影响结果。
例如，体检管理要解决的问题是预约安排不合理的问题，同时避免出现体检部门超负荷。
当然，医院本身也有可能通过多个信息系统的打通，来解决医院内部信息孤岛的问题，从而方便各类信息的流转，例如从门诊到住院的信息的打通，就可以方便住院人员的全流程服务。而针对如住院，体检，急诊等各项业务的信息管理，也都有相关的业务目标，这些目标可以进一步梳理。
- 项目范围
a. 划分主题域
什么是主题域，我个人觉得挺难理解的，但是在医院里，我们讲将系统划分成住院管理，门诊管理，体检管理、门诊管理，就很好理解，而这些就主题域，简单地讲，就是和业务部门一一对应的（当然，业务部门要非常清晰的职责划分）。
b. 确定主题域的用户
如门诊部门使用系统的有体检者，前台工作人员，客服工作人员等
【配图】
c. 初步梳理事件和报表
如门诊管理主要事件有：
- 体检者进行体检申请
- 客服中心查询体检情况
- 系统通知用户取报告
如体检管理输出的报表有： - 体检申请表
- 体检登记表
- 体检报告
-
各体检项统计表
项目范围确定主题域与事件，通过事件推测相关报表
.
二、需求捕获阶段，输出用户需求
需求捕获的过程，是通过需求调研，输出更详细的用户活动，以及每个活动的步骤的过程。
需求捕获的过程进一步探索，找到需求是什么的答案
这个阶段，主要是从用户的角度，出发挖掘：
- 每个事件下，有哪些活动。
例如：事件“体检者做体检申请”，那么可能会经过的步骤如下所示。这就是需求捕获需要挖掘的第一个层次的答案。
分析一个事件包含哪些活动
- 每个活动，都需要经过哪些步骤
例如，针对以上事件下的活动，体检者填写体检单，那么我们要问，填写体检单的步骤有哪些？这就是需求捕获要挖掘的第二个层次的答案。
分析一个活动包含哪些步骤
而这个过程，就是用户需求逐步清晰的过程
完成业务活动和业务步骤的分析
当然本书关于需求调研放在需求捕获的 阶段，我个人觉得是可以斟酌的。按正常的项目过程，可能从项目立项的时候，需求调研就已经开始了。只是书本把需求调研的过程集中在这个部分进行描述而已。
不过这并不影响本书的理论的完整性。
本章有两个亮点：
-
介绍需求调研过程的一些沟通原则，和沟通的话术。
很多书都会讲需求调研的过程步骤，很少有工具书同时指导你如何沟通，作者提供给我们更深层次的需求调研的沟通过程，不让需求调研只做表面功夫。 -
介绍了需求调研结果的记录工具。
另外，需求调研结果的记录工具，很多工具也很少讲，然后就直接过渡到了建模和设计的过程了。本书把用户需求和软件需求切割开，这个需求调研结果记录的工具应该功不可没
“三、需求建模阶段，将用户需求转化为软件需求
需求建模是业务离开发最近的地方。它依然阐述业务的需求，用户的需求，但是这个过程将这些需求转化为结构化的形式（我们也可以把它当成一种量化的，可以被开发理解的文档内容），以业务活动流程图，类对象关系图，用例以及用例规约等方式表达出来。
业务活动图示例
类对象关系图例
用例图图例
用例规约表图例
另外，本阶段生成的用例规约里面，加入了人与系统的核心交互过程，把系统当成黑盒子，把人要在系统做的操作，以及系统自己要提供给人类的反馈，系统自己的操作，一步步地表达出来。这样就构成了我们对系统的需要，建立了系统的需求。
总结
本文章最前面，我没有直接定义业务需求，用户需求，和软件需求。因为在想，大部分人应该都跟我一样，没有了解需求分析的过程之前，这三个概念直接抛出来，还是似懂非懂。
这里应该就可以稍微讲下我对这三类需求的理解了。
还是从体检系统出发：
-
业务需求就是业务目标，是企业/组织希望通过系统要解决的问题。
-
用户需求就是为了达成业务目标，需要何人做何事。而在系统主题域划分为事件的时候，用户需求已经开始了。最终就变成了用户的实际操作步骤。当然，用户需求的组织过程（如主题域，事件，活动等）也属于用户需求的一部分。
用户填写体检单的操作步骤
-
软件需求，是把系统当成和人交互的另外一个人，把用户需求，转化为用户和系统交互的具体过程。同样地，软件需求的组织过程（主题域转化为子系统，业务事件和活动转化为业务流程，报表，数据，用户等抽象为类对象）也属于软件需求的一部分。
用户填写体检单和系统之间的交互过程
网友评论