名词解释篇
不知道有没有人和我一样，就是在遇到一些专业的名词的时候，都如临大敌。如“业务”、“愿景”、“目标”、“需求”、“需要”、“业务需求”、“软件需求”、“核心域”，每次看到软件工程相关的书，就会开始很头疼，软件工程的书，很多都是程序员出身的专业人员写的。我想着，是否程序员都很有创造力的，所以他们也会在软件这个领域创造自己的词汇。另外一个方面，可能也是因为很多原始的讲软件工程的书，都是外国人写的，所以外文翻译过来，可能就会让人需要花更多时间去思考。
《软件方法》这本书真的很好，把软件需求的理论都写的大道至简，但是我看书的时候，最头疼的依然是专业名词。所以在看书的过程，也琢磨了一点时间里面的名词，然后整理了。现在翻看早前写的读书笔记，觉得现在已经都不需要去看对照理解，也基本知道是个什么东西了，不过也不想浪费了这个整理。
所以想着也分享出来，如果你也在看这本书，关于名词的解释，可以看看有没有需要用到。
名词1“业务”：
例如，我是一个软件产品的产品经理，那么我涉及的业务就是软件业务。我是一个中餐的厨师，那么我涉及到的业务就是厨房业务。有个公司是卖塑料的，那这个公司经营的就是塑料业务。
软件产品的存在，最终都是为了人类的某项专业，某项事务而服务的。所以在软件运行的大环境中，软件服务到的专业的事务，我们称之为业务。
例如医院使用的医疗系统，就是为医疗业务而服务的。学校使用的教务系统，就是为教学业务服务的，电商公司使用的电商系统，就是为电子商务（网上的商业交易，网上的买卖）而服务的。这里的业务，如医疗业务，教学业务，电商业务，都只涉及软件系统要服务的对象。它们大部分，在没有软件时代就已经存在了，如医疗业务，教学业务等。也有少部分，是随着软件的诞生而新兴的。
所以，我们讲业务不一定需要软件，提供特定服务的软件则一定是因为某业务的需求，才出现，用于提供服务的。
名词2“核心域”：
有一些书，会把业务，叫做“核心域”，我们就看到“核心域”，把它当成业务范围就可以了。更精确地说，就是“软件要核心服务的领域”，称之为“核心域”。
名词3“愿景”：
愿景的字面意思，就是愿望场景的描绘。例如有一本书的名字，就叫做《沙滩上的钢琴》，作者希望有一天能实现的梦想，就是在沙滩上弹奏钢琴，将远期追求的梦想或理想，图像化，作为最高的目标去追求。它具有结果性，是一切奋斗，一切努力的本质原因。
名词4“目标”：
愿景也是目标，但是目标不一定是愿景。愿景有两个特性，一个是图像化，具体化。目标不一定图像化，不一定具体，它也有可能是阶段性的，可大可小。例如，小f说，我希望3年之内能结婚，这是一个目标，但是它不描述愿望场景。而如果小f说，我希望在3年之后第一天的清晨，能穿着婚纱，在海滩上，吹着海风，举行结婚仪式。那它就是一个目标，也是一个愿景。
当我们很难区分哪个是哪个，其实，就把它们都当成目标，再判断一下是否有画面感。
当然，在软件的愿景，以及软件的目标的提出，除了是个目的，还要求可量化，这是区别于其他目标定制的一个更细节的地方。
名词5“需求”vs“需要”：
看到需求和需要，你会不会和我一样一直傻傻分不清楚，然后看到其他人都懂的时候，就会想，他们是怎么知道的，那种好奇的想法。
痛苦的点还在于，你在不同的地方还要加以区分，避免人家说你不专业，真是头疼，为了一两个词，也需要琢磨琢磨。
这两个词，可以用一个场景的描绘来加以区分。想象你有一天心血来潮去一座非常高的高山爬山，在下山的路上，你的肚子纯天然的咕咕咕地叫，饥饿围绕着你，你是走一步，你的肚子就在告诉你，我饿了，我饿了，我需要被喂饱。
你就看着沿途，是不是有小驿站之类的，好不容易看到了一个卖豆腐花的，那个心里哗啦啦的被它的存在，感动的“痛哭涕零”，终于不用饿肚子了哟。你买了一碗豆腐花，匆匆下肚，你的肚子终于才没那么饥饿。
这个场景里，肚子饿了是人的本能，填饱肚子就是人的需要。而需求，是在你可选择的范围内，“求”得满足你需要的服务，还可以讲“为了满足需要，而希望求得的东西”。在这个案例中，需求就是吃一碗豆腐花。
那在这里又有另外一个问题了，需要、需求和目标的关系是什么呢？我们讲目标是有层次的，那么需要是一个高层次的目标，更加抽象化，而需求则是较之比较低的层次，更加具体化。
这样，就不用担心什么时候用目标，什么时候用需要，什么时候用需求，什么时候用愿景了。
例如，我饿了，我希望填报肚子（需要），我希望最后能吃不了兜着走，乐呵呵地回家去（愿景），那为了能达成需要，实现这样的愿景，我打算吃好几碗豆腐花（需求）。
而这些，都是我的目标，只是目标是在什么层次而已。
需要（Needs）：人类没有得到某些满足的状态
需求（Demand）：人们有能力并且愿意购买某种产品的愿望
简单地讲，凡是能买卖的都是需求，不能买卖的都是需要
名词6“业务需求”：
坊间流传的“想要一匹更快的马”，还是“想要能快速地从A点到B点”，可以归属到“交通业务”。
想要解决“快速地从A点到B点”是需要，需求则是想要“一匹更快的马”，或想要“一辆车”。
结合起来描述就是：需求1：希望求得“一匹更快的马”，以期“更快速地从A点到B点”
需求2：希望求得“一辆车”，以期“更快速地从A点到B点”。
那我们回到医院的医疗业务。他们希望缩短“患者看病时间”，这是需要。
这个需要，可以通过服务流程效率改进达到，如增加配备门诊，收费等相关系统的工作人员，这样患者就可以分流服务。
也可以通过硬件设备辅助的手段达到，例如，原先的测血压需要人工压缩来测量，现在的机器设备，只要手伸进去，就可以自动压缩，并很快出结果，这就也是缩短了患者停留的时间。
还可以通过信息化系统，让信息的流程更为高效等。下面的增配人员，增加辅助硬件设备，增加信息化系统，就都是业务上的需求。
由于业务大部分都比较复杂，所以业务需求的分解，很多都通过“流程”图来体现，方便从时间线上来看各项事务，优化各项事务，以及优化各项事务的协作方式，这个“流程图”，我们就称为业务流程图。从而拆分出真正的业务需求，以期满足业务需要。
当然由于业务需求是从业务需要引申出来的，所以一般地为了能满足前因后果的逻辑严谨性，所有人们讲业务需求，或讲业务需求梳理的时候，也会带入“业务需要”，把需要和需求都一并讲明白。
名词7“软件需求”和“系统用例”：
原始的业务流程图的每个环节，都采用何人做何事的方式来描述。
但是当我们想在这个“何人做何事”的过程中，提炼出哪个人做事，是利用了软件系统进行辅助的。换个角度讲，业务上需要软件提供什么服务，才能实现业务的需求，对业务直接产生价值。
我们可以把上面讲的业务流程图，转化成业务序列图，就可以很好得观察到“软件需求”了。
简单地举例，我在写报告的时候，使用word文档编辑文字。那么写报告就是我“业务”上的事情，可以表达到业务流程图中，而使用word文档编辑文字，就是利用了“word”这个软件系统辅助完成业务事务，可以在业务序列图中体现出来。具体业务流程图和业务序列图要怎么画后面的章节会讲。
软件需求，就是一系列的讲“...请求软件提供...服务”的集合，就构成了软件需求的集合。
而“系统用例”，就是这些“...请求软件提供...服务”中的任意一个，通俗地理解，就是系统的用户操作事务（事例）。
软件需求在业务领域，是一个解决方案。
但是在软件设计领域，就会内化成设计之前提出的问题，即“我要如何让软件拥有做...的能力”，这个时候系统用例规约，就悄悄出场了。
名词8“系统用例规约”
系统用例描述“用户使用系统操作什么事务”，用例规约，描述“用户如何使用系统操作事务”的规定和约束。
想要知道用户如何操作，除了知道用户会有哪些感知能力和操作行为，如“视听嗅味”，如“说”，如“写”等之外。还需要知道系统是如何接收请求，以及提供反馈的。这样，才能知道他们要怎么互动，这个过程有点像人和人合作的过程，想要合作共赢，就要知彼解己，人和人的对话如此，人和“系统机器”的对话过程也跳不过这一步。
当知道人和系统怎么互动了之后，就可以把“系统必须接收什么输入”，“系统必须处理什么”，以及“系统必须反馈什么结果”，这几个重要的部分梳理出来。
当然，实际的交互还有很多繁琐的神奇功能，例如系统接收输入的时候，人在系统的操作，可能不只一次，可能会录入多个表单，但是在用例规约，规定用户使用系统，只要能把用户不得不做的核心交互，也就是没有这些核心交互，就完不成“用户使用系统操作事务”这件事情就可以了。剩下的灵活多变的细节交互，可以留到用户体验设计。
上面讲的人和系统的交互过程，我们也可以称为“系统使用场景”，刚好匹配新兴互联网产品设计的应用场景。除了交互过程，我们还需要在这里把一些用户操作事务的要求体现出来，例如，做一个辅助人口采集的软件，那么在采集人口的事务中，就必须规定人口要采集哪些信息，如果是涉及到一个城市的人口采集，要求完成的时间又很紧迫，那么采集的效率就有要求了，就要根据当时的时间，和能采集的群里，进行折算，算到每人每天要采集多少，再进一步折算系统的采集表单就要设计的够简单好用，系统的数据提交就要足够快，这些，就又成为了对系统的质量上的要求。另外，软件系统自己本身也有限制，如只能在Android手机上使用。
总的来讲，用例规约，描述“用户如何使用系统操作事务”。它除了描述使用的过程交互之外，还对于使用过程的内容，操作等做了各种各样的要求和限制。目的都是能支撑其完成“提供...服务”的使命。
名词9“业务工人”
业务流程里，“何人做何事”的何人，就是业务工人
名词10“业务实体”：
业务序列图，“提供...服务”的系统，就是业务实体，可以把它理解成业务“机器人”，是另一类业务工人（业务实体的理解）
名词11“系统执行者”
系统用例中，“用户使用系统操作什么事务”，这里的用户，就是系统执行者，当然，用户不一定是真人，也可能是另一个“系统”机器，它具有主动发送请求的能力。
名词非官方解释参照表
提供一个词汇理解非官方对照表，如果后面遇到了这些名词，但是忘记了，可以回来翻阅
参考书籍：《软件方法（上）》潘加宇