今天我准备再写一篇软件需求人员能力提升方面的文章，也就是把这个问题进一步谈透。对于IT行业来说，前面谈到更多的是招聘软件开发或架构设计人员不容易，特别是架构人员也难以培养。而对于软件需求人员也是同样的道理。

　　软件需求不同于用户需求或原始需求，对于业务需求往往你无需任何的IT技术背景就能够提出你的需求和问题，而对于软件需求则涉及到业务需求分析，分解，形成完整的业务解决方案，复杂的还是涉及到业务建模，最终才形成软件需求。

　　因此软件需求人员实际是衔接业务用户和内部技术团队的关键桥梁，软件需求和业务建模做得好，技术实现本身也更加高效。同样，一个软件系统最终实现出来灵活，可复用，那么首先是业务上进行了抽象和可复用，其次才是技术上可复用。

　　举个例子来说，对于一个报账系统报销流程，里面涉及到日常费用，差旅费，采购报账，借款报账，资产报账等各种类型的报账单据。如果你不抽象，那么最终开发人员需要实现50种深圳更多的报账单据功能。但是有经验的软件需求人员可能会进行业务建模和抽象，即将报账单据模板化，形成业务模板。

　　当然这个也可能是技术人员提出的方案，但是理想的情况是需求人员提出业务模板的概念，技术人员再考虑如何通过灵活配置的方式来实现。

　　什么叫软件需求分析和开发能力，因为我们经常会分不清楚用户需求和软件需求。在这里再次重申下这两者的差别。

　　对于用户需求来说更多的是用户陈述清楚当前的问题点在哪里？比如当前手工录入单据导致效率低，无法进行项目全成本核算，领导无法在月初快速地查询到财务报表数据，账面和实际货物进行出现不符合等。

　　这些是典型的业务或用户需求，即具体的问题，基于问题希望达到的目标。

　　而软件需求人员要回答的是什么呢？简单来说就是我帮助你构建一个什么样的IT系统，这个系统有哪些功能，通过这些系统能够解决你当前的问题。

　　即软件需求人员一般是针对用户提出的原始需求或问题，给出了明确的业务解决方案和系统功能说明。包括究竟是构建一个新系统，还是在原来的系统上做变更优化，新系统究竟包括哪几个功能来满足你的要求。

　　当我谈到这里的时候你应该清楚了软件需求人员给出的是解决方案，这个解决方案还不仅仅是业务解决方案，而且包括了业务解决方案如何在系统中通过多个功能的实现来落地的解决方案。

　　在传统的软件工程里面实际并没有去详细划分为软件需求和软件架构设计两个角色，而是只有系统分析员这个角色。而当前一般将两者分离，那么软件需求人员就需要回答业务系统长什么样，应该提供哪些功能，这些功能为何能够支撑你的问题并达到业务目标。

　　而对于软件架构设计更多的则是各个业务功能究竟内部应该如何设计，如何去实现。实现中采用哪种开发框架，分层模型，从模块到组件如何进一步划分，如何设计接口，如何集成等问题。

　　一个好的需求人员实际是承担了部分系统分析的角色。从业务系统到业务模块，从业务模块再到详细的业务用例和系统用例。里面的难点不是在于你如描述一个个详细的用例，而是找到这个系统需要实现的所有用例，同时规划清楚这个业务系统究竟应该划分为几个模块来实现。

　　也正是这个原因，我再次对接徐锋老师的《软件需求最佳实践》这本书，这本书实际对整个需求分析和需求开发，业务和用例建模过程进行了完整的描述，并总结为SERU框架和方法论，值得参考和需求。

　　在这里我再对这部分核心思想做个简单总结。

　　即当我们分析一个业务的时候，核心仍然是业务流程分析方法，比如一个最简单的差旅费用报销，我们完全可以对其进行详细的流程分析。

　　但是我们的目标是构建一个报销子系统。

　　因此这本书给出了一个关键点，就是刚开始的梳理和分析你完全没有必要马上落入到详细的流程梳理细节，而是应该将报销子系统做为一个黑盒系统，首先应该是去梳理该子系统和外部角色，乃至外部关联系统的接口关系。

　　即报销人员核心交互是提交出差申请，预订酒店机票，提交报销，查看付款进度。而公司领导的作用是审核单据。财务人员中会计是核对单据，进行凭证记账，而出纳是付款审核。同时你会看到这个系统和外部有集成和关联。即报销系统需要和携程集成，实现机票和酒店的预定。需要和银行集成，来实现付款审核通过后自动进行付款操作。

　　当你梳理清楚这个后，注意不仅仅是核心业务活动出来了，更加重要的是业务角色也梳理出来了。接着你做的才是进行详细的业务流程梳理和分析。

　　由于角色已经清楚，自然可以画出更加详细的跨职能带的业务流程图。

　　在这个业务流程详细梳理完成后，关键的业务活动全部出来，这个时候你需要考虑的就是哪些业务活动应该转换为业务用例，哪些应该转化为业务用例的规则，哪些业务活动本身是线下活动无须通过业务系统功能实现。

　　当你把一个大业务所有的业务场景，业务流程全部梳理完成后，你会发现很多业务活动，业务对象是重复的，那么面对重复一个关键步骤进行整合，是抽象，如果要说业务建模，这个时候就出现了关键的业务建模活动。

　　到了这个步骤，业务用例全部梳理清楚。

　　业务用例全部梳理出来后，你还得做一个关键事情，就是划分业务模块，哪些业务用例应该划分在一个业务模块里面。也就是说你需要分析哪些业务活动耦合性强，应该内聚在一起，哪些相关性低，应该拆分。

　　这些内容你会看到软件架构设计也在做，但是架构阶段以及到了详细的系统组件划分和系统接口设计，而这里还是业务模块和业务接口。

　　但是整个分析方法和思路实际上很多是类似的。

　　当这些内容全部梳理清楚后，才进入到业务用例或系统用例的详细描述阶段，在这个阶段你才是需要详细的通过用例分析和设计方法，对每个用例的业务场景，基本流，扩展流，业务规则，业务对象进行详细的描述和说明。

　　通过这种方法进行软件需求分析，你会发现最终所有的系统功能点都不是孤立的，都是你一步一步地从上到下分析出来的，是为了支撑业务场景和业务流程服务的。

　　在前面一篇文章我已经提到，要做软件需求这个岗位角色，基础的前导知识必须具备，这个知识包括了业务和技术两个方面的内容。如果你是业务人员转软件需求，那么就需要补充技术类知识，如果是技术人员转软件需求，那么就需要补充业务类知识。

　　在业务方面即是围绕企业核心业务价值链的大框架的业务理解，从产品研发到生产，物流，市场营销，售后服务，财务和人力资源等组织支撑能力等。对企业这种端到端业务必须有粗粒度的框架性的了解，你可以理解为泛读，重点是形成脉络框架。

　　其次才是对你从事的业务域的关键业务知识的详细学习，如果你做供应链类系统，有专门的供应链管理类书籍可以阅读，包括基于Scor模型进行对比参考。如果做产品研发，有IPD和HPPD完整的方法论可以参考；每一个业务域你都能够找到对应的专业书籍进行学习。

　　在技术方面重点简单来讲核心是软件工程和数据库。软件工程学习仍然是偏粗粒度地学习，这个需要覆盖IT基础设施和资源层，中间件，应用常用分层模型，同时基于软件生命周期，V模型等清楚地了解一个业务系统，一个软件应用是如何从无到有的，软件开发中涉及到的需求，设计，开发，测试等各个关键角色活动，是如何沟通协同的。

　　还有一点就是数据库，为什么数据库很重要。任何业务的学习实际都包括了业务流程和业务对象，理解业务对象模型实际对理解核心业务起到很重要的作用。任何一个古玩论坛业务功能的实现你会看到软件功能界面，操作对应的是我们分析完成的业务流程，而操作完成的结果形成的业务对象单据，对应的是数据库。当你理解清楚数据库，数据表对象关系后，你更加容易理解业务，理解业务和技术实现之间如何映射。

　　学习的切入

　　你看任何前人留下的业务需求，业务方案或系统用户手册等文档。实际上核心仍然是业务流程，业务对象，业务岗位角色。这些就是你必须搞清楚的内容。

　　在这个之前你可能还会看到大量的业务专业术语，这个本身又是你学习的基础，你要有意识自己去购买书籍，搜索网上资料对基础的专业术语知识进行学习。比如你做财务类业务系统，那么最好是要构建相关的财务类业务书籍进行阅读和学习。

　　当基本的业务流程你能够理解后，接着就是业务对象要搞清楚，包括有哪些业务对象，这些业务对象的关系是什么，这些业务对象随着业务流程是如何流转的。

　　比如在供应链流程里面我经常举例，你看到的是一个完整的业务流程，但是实际里面涉及到从成教招标请求，中标结果，采购请购单，框架协议，采购订单，采购接收单，入库出库单，资产转资单各种业务对象和单据，你需要了解的是完整业务流程流转中这些业务对象之间的映射关系。

　　当你把业务术语，流程，对象三者都搞清楚后你基本的业务才算清楚。

　　当然一个软件需求人员进入项目后，尽快地熟悉你当前的业务系统是最好的快速学习和上手的方法，你应该有意识的把你做的业务系统的所有功能全部测试和验证一遍，对着用户手册逐个操作所有的功能。

　　当所有的功能都操作完成后，你接着要基于业务流程将所有的功能串联起来，即实现一个业务功能究竟是需要系统里面哪些功能共同协作来完成。

　　任何一个功能在操作完成后都需要清楚：

　　该功能有无上游功能，比如你做采购接收，如果没有形成上游功能形成采购订单，你如何做采购接收。其次是该功能完成后对应的数据流入到下游哪些功能，还是仅供查询，比如项目立项申请完成，形成数据流入到项目可研功能。

　　最后是该功能本身存在哪些引用，比如你才操作报账单申请功能，你会发现要选择项目，选择报销类别，那么你就要搞清楚这些功能来源于哪些，是数据字典，还是项目基础信息维护。或者你发现这个数据源头在系统里面没有对应的维护功能，那么这个时候自然就是对应到外部接口同步过来的数据。

　　任何一个功能当你能够清楚地回答：

　　这个功能上游功能是什么？该功能需要引用哪些数据对象？该功能形成什么数据？该功能形成数据流入到下游哪些功能？

　　如果你能够清楚地回答上面这些问题，那么这个业务系统，包括业务系统里面的业务功能，大的规则，数据对象，对象之间的关系基本就搞清楚了。

　　业务能力的深入

　　业务能力的深入实际包括两个方面，其一是业务建模，其二是解决方案能力。

　　业务建模这个词说起来感觉很复杂，也很抽象。简单来说业务建模就是软件需求人员必须回答用户提交的问题，你最终会给用户一个什么样的系统，这个系统大概长什么样子，有哪些业务功能来支撑问题的解决。

　　但是需求人员并不会回答这些功能通过哪些组件，采用什么技术框架，语言来实现。

　　举个例子来说，你需要修建一个房子，那么软件需求人员应该能够给出一个完整的房子模型给用户看。但是并不会告诉用户这个房子应该如何建造出来。

　　所以现在一般软件需求人员一般会承担了系统原型设计的工作，通过原型设计和用户沟通最终的解决方案。

　　那么这个业务建模如何完成？

　　前面也谈到了建模的核心就是抽象，业务建模就是对业务的抽象。抽象简单来说就是归纳共性，参数化差异。但是基础是首先要有具体的问题点，需求点，或具体的业务活动点。而这些内容来源于前面谈到的业务需求收集，详细的业务流程分析和梳理。

　　通过分析梳理先找到一个个业务活动，一个个业务对象。

　　找到这些内容后你才应该去考虑这些内容应该如何做业务抽象，哪些可以归类，哪些应该模板化，哪些应该合并，哪些应该分解等。对于这个内容很有意义，实际方法和我前面很多谈EA企业架构文章中思路是一致的，后续再专门写文章来谈。

　　其次就是业务解决方案的能力。

　　业务解决方案的能力不就是问题分析和解决能力吗？这个在我产生思维框架模型，问题分析和解决方法论里面有大量说明，那么回到业务解决方案这个话题上来看，你该如何做？

　　任何解决方案的能力都包括了问题域，经验库，模式匹配三个方面。对一个问题你将问题定义和梳理清楚容易，但是难的是你的经验库，你的模式匹配能力。

　　如何提升你的经验库，自然是大量的实践，不仅仅自己负责的业务系统的需求熟悉，而是应该扩展到整个企业业务价值链，核心业务域，业务主流的参考模型，成熟度框架的学习。

　　举个最简单的例子，供应链系统该如何分业务模块？这个实际并不需要你太多思考，业界标准的Scor供应链模型可能已经给出了初步框架，你需要的仅仅是结合自己的业务情况做小修订和完善即可。

　　而对于模式匹配能力则是更加困难的一个能力，模式匹配能力核心仍然在于如何去匹配，粗粒度的知识是无法匹配的，你需要的是日常大量实践后的复盘，同时将复盘内容形成一个个细粒度的原子知识点，这些知识点才可能去匹配。

　　举个例子，前面谈到报销单，你实践后应该得出如下经验点。即大量的同种业务申请单据的实现，应该考虑业务模板化方式。

　　技术能力的深入

　　对于业务人员来说你只需要告诉用户提供了什么业务功能，这个功能长什么样子就可以了。但是对于软件需求人员，你就需要进一步理解清楚，这个业务功能底层的关键实现逻辑，对应的底层数据模型，数据库表是如何的。

　　软件需求人员技术深入，第一步就是数据模型和数据库表。

　　当你完成了业务流程和业务功能之间的衔接，即一个完整的业务流程对应到系统里面哪些业务功能后，技术深入的重点就是去了解清楚底层的数据结构，以及数据库。一个业务对象变成了数据对象，而数据对象最终又转变为数据库表持久化存储。

　　任何一个业务功能，在你完成了黑盒层面的理解后，都需要去了解支撑该功能的底层数据模型是如何的，对应到后台哪些数据库。一个业务操作发生后究竟会影响到哪些数据库表数据发生变化。数据库表和表之间什么样的关联依赖和约束关系等。

　　到了这里基本就完成了业务到技术层面的关键映射。

　　任何一个需求人员都应该了解核心的底层数据模型和对象结构，业务系统和外部的接口。当熟悉了这些后，你进一步具备业务系统的灰盒测试能力。

　　即使你在前台进行了UAT测试后，你可以直接查询后台数据库进一步对数据是否正确，多个数据库表的勾稽关系进行验证。要明白不是所有的业务功能，在前端输入后，都会有对应的功能帮助你验证输入是否正确。

　　一个软件需求人员可能并不会涉及到具体的代码文件，但是往往都是做UAT测试的高手，能够代替用户做完整的端到端业务场景验证，同时又具备足够的数据库Sql技能，能够快速的验证数据，提取数据进行报表分析等。