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