软件需求之道现实抽象和业务建模

　　软件需求概述
　　在去年7月份的时候，我在头条号上发过一篇关于《软件需求分析和开发最佳实践》的文章，这篇文章重点还是基于徐锋老师的软件需求最佳实践一书，结合案例进行展开，讲述了软件需求分析和需求开发的完整过程。
　　在徐锋老师的这本书里面，给出了SERU需求过程框架，将需求过程分解为了三个阶段，第一个阶段是需求定义，重点是主题域划分和业务事件识别。第二个阶段是理清需求框架和脉络，重点是通过业务流程图转到具体的领域类图和用例图。到了第三个阶段重点就是填充需求细节，包括用例的详细编写，界面和交互设计等。
　　对于这篇文章的内容可以参考：
　　软件需求分析和开发最佳实践
　　我印象里面是2006年左右在中兴通讯的时候，为了配合进一步的需求过程改进和CMMI三级的成熟度评估，公司专门邀请了徐锋老师进行了为期两天的需求分析和需求开发内训。这次培训整体收获还是很大的，进一步完善了自己需求分析和开发的整体方法论，并将原来离散的一线知识点进行了有效的衔接和串联。
　　类似的还有项目管理，实际也是在中兴已经做了3年左右的专职IT项目管理后，才去参加了PMP培训和认证考试，将项目管理知识体系进一步系统化。
　　这类培训最大的好处就是对你实践过的内容进一步进行体系化整理，通过培训来帮助你将已有的知识和经验点形成一个完整的知识体系结构。
　　为何今天要再谈下软件需求？
　　对于软件开发全生命周期来说，需求是处于相当重要的一个位置，需求完成了现实世界的第一次抽象，形成了业务模型，架构师完成了第二次抽象，形成了可实现的技术模型。
　　最近几年低代码开发平台非常的火，在前面我也给出了明确的说明，即对于任何一个软件应用的开发来说，最难的是需求人员做的现实世界到抽象世界的模型转换，这个是软件开发的根本问题，当前也没有很好的银弹可以自己解决。
　　所以当前很多低代码开发平台或工具你要看到，如果你真正想用得好，重点已经不是技术或编码人员能力，而是你使用这个平台的需求人员的建模能力。
　　但是当前实际情况却是软件需求类人员包括技能要求没有受到足够的重视，由于需求分析和开发本身不充分，不完整等问题导致后续大量的需求变更，返工等工作。
　　传统需求工程和敏捷方法论
　　特别是在类似Scrum敏捷开发推进的过程中，这个问题更加突出。
　　对于Scrum敏捷开发，我在多年前就给出过一个很明确的结论，这个结论就是对于一个全新的大业务系统开发不适合一开始就进行敏捷开发，核心原因就是敏捷开发无法保证一个全新系统的业务建模，业务架构和技术架构的概念完整性和一致性。
　　当前推广Scrum敏捷开发的很多，我们可以自己Review下，在敏捷开发过程中，业务流程，业务场景，用户故事，故事描述这些内容感觉都有，但是这些功能最终都为业务功能的实现服务，而我们并没去思考支撑这些业务功能需要一个什么样的业务模型抽象。
　　也是在06年左右，公司和团队都开始关注交互设计和易用性，并引入了敏捷开发方法，当时最大感受就是类似业务场景，分角色设计，UI和交互设计等方面的内容，这让我能够在进行需求分析的适合更多的从业务场景，从用户角度去思考。
　　但是这些内容的引入并没有形成完整的需求工程，也并不适合要给全新系统的需求阶段工作。全新系统的需求工作仍然应该遵循前面谈到流程驱动，业务域边界划分，核心业务用例和业务对象识别，用例和规则细化等关键方法论。并通过业务流程，业务域，业务用例，业务对象，业务规则整理形成完整的抽象业务模型。
　　这个业务模型是实现整个业务，并支撑产品功能实现的基础。
　　从需求到产品经理
　　对于做传统toB企业内部信息化的可能都比较清楚，一般会设置独立的软件需求岗位，负责软件需求和界面原型设计。进入到很多互联网产品开发后，整个软件过程更加敏捷化，因此也可以看到软件需求这个岗位逐渐被弱化了，更多的是产品经理来完成。
　　也就是产品经理负责需求，但是产品经理对需求的输出重点又放在了UI原型和交互设计上面，而弱化了全业务流程，全场景的业务建模和分析工作。
　　简单来说产品经理更多做的类似用户需求和业务用例事情，而非软件需求，那么我们需要的从现实世界到软件世界的第一层抽象，业务建模，往往就不充分。
　　当然你也可以说互联网很多SaaS应用本身前期需求就不明确，无法给出完整的业务模型，只能够是走一步看一步，逐步的通过版本来持续优化。
　　如果你是要给互联网产品经理，那么你是按下面哪个方式在思考：提供哪些业务功能给用户使用，满足什么样场景需求构建一个什么样的业务模型，这个模型支撑哪些业务场景
　　我为何提着两个思考方式，简单来说，如果我们研发一个产品，一开始就不是基于业务模型抽象来驱动考虑，如何满足业务场景需求，而是简单的业务需求来一个做一个，那么我们很难做要给真正产品化的产品。
　　大部分产品经理往往都是第一张思考模式，即产品经理解决了从市场和业务场景出发，真正提供给最终用户要给好用，易用，解决用户痛点的产品。但是并没有解决业务的抽象问题，后续模型如何更好地支撑业务问题。
　　如果一个需求人员仅仅解决的是用户要啥，那么他仅仅是一个需求提出者或业务需求人员。而真正的软件需求人员在搞清楚了用户要啥后，还需要进一步搞清楚，需要构建一个什么样的业务模型来支撑用户要的东西。
　　而且我这个业务模型还能够更好地传递给技术实现人员。
　　结合我前面谈到的内容，再给软件需求一个说法，即：软件需求应该是将用户对一个软件系统功能的希望转变为文本，符号或形式化模型的抽象过程。需求的过程不仅仅包括了最终应用功能界面静态呈现，也包括了功能实现的内在机制和逻辑说明。需求分析核心逻辑
　　今年在远行科技内部培训开课，我准备进一步安排人讲解需求分析和开发方法，不是讲具体的需求工具和技术，而是进一步梳理清楚需求分析和建模的核心逻辑。
　　需求过程重点就是需求定义和获取，需求分析，需求开发，需求验证几个关键内容。而对于需求管理即包括了需求变更管理，需求追踪，需求版本和基线管理等。
　　对于软件需求开发来说有两个核心内容，一个是需求分析，一个是需求建模。
　　需求分析的逻辑
　　需求分析简单来说就是以原始需求和用户需求作为输入，通过需求分析，选择一种业务导向的线索将零散的需求串起来，形成体系完整、内容清晰的脉络与框架，以指导后续的设计、开发工作，并最终将需求分析产出的工件输出给开发团队。
　　需求分析就是先分解，再提炼，并在这个过程中消除矛盾。
　　分解是一种自顶向下的方法，其目的是为了降低问题域的复杂度，通过对问题域的逐层分解，将问题域分解为相对独立的更小的问题域，从而降低其复杂度，最后分而治之各个击破，得到基于每个分解后域的需求分析结果。
　　需求分析的核心内容就是分解抽象。
　　也就是说需求分析过程中有一个关键动作即通过分解完成业务域或业务模块的划分，将待构建的目标系统分解为模块，再将模块分解为不同的业务单元，最后基于业务单元分别进行分析并得到需求分析结果。
　　业务模块的划分往往是后续架构设计和系统组件划分的一个重要参考，而现在大部分互联网应用需求分析来说，这个过程被省略掉，全部由架构或技术角色来完成。
　　需求建模的逻辑
　　建模的目的是帮助我们按照实际情况或按我们需要的样式对系统进行可视化，提供一种详细说明系统的结构或行为的方法，给出一个指导系统构造的模板，对我们所做出的决策进行文档化。
　　建模的例子在现实生活中无处不在，比如大家常见的对于建筑物的建模，通过模型建筑师可以在真正建造建筑物前将建筑物可视化，从而可以对现实进行简化及研究，从而使用较小的成本发现并修改问题。
　　同样的，需求建模是需求分析的主要手段，它通过简化、强调来帮助需求分析人员理清思路，对问题域进行研究并最终用于和上游及下游进行沟通。
　　如果是对于企业级的业务和需求分析，我们可以参考类似企业架构中的需求和业务建模框架，比如企业架构模型中的Zachman框架，其中的企业模型和概念模型很多就属于需求层面内容。而类似TOGAF方法论中的业务架构和数据架构的建模思路，我们常说的ARIS的流程分析和建模方法等都可以作为我们在进行端到端需求流程和需求分析时的重要参考。
　　而如果到软件需求阶段，可以看到，更多是采用用例，类图，活动图，状态图等来完成整个需求过程的业务建模。通过这些模型间的协同来完整描述业务。
　　简单来说，需求建模的核心逻辑应该是通过抽象化的模型语言来完整的描述业务的静态呈现和动态运转机制的一个完成过程。
　　需求建模的过程本身应该是业务流程和场景驱动的，通过流程分析来识别关键的业务活动和业务用例，同时抽象和定义活动中承载的业务对象和数据，并最终通过多个用例活动协同来完成整个业务流程。
　　需求分析和建模过程说明
　　在这里，我再通过一个最简化的基于流程驱动的例子来说明整个流程驱动的需求分析和建模的核心过程和逻辑。实际上这个方法在远行SOA团队进行SOA架构规划，企业架构规划的时候也经常会采用到。
　　当我们接手要给需求的时候，往往就需要进行需求调研和分析，搞清楚业务流程和业务场景。而业务流程中涉及到业务阶段，岗位角色，关键业务活动，业务对象单据等信息，这些信息都是需求建模的关键。
　　跨职能带流程图由于可以同时体现阶段和岗位角色，因此更多的会使用到需求阶段的流程分析和梳理过程中，比如一个简化的流程如下：
　　在流程的分析中，关键活动，阶段，岗位角色，活动间交互协同，活动承载业务单据对象等信息都会涉及到，而这些就成为后续需求建模的基础。
　　需求分析有一个重点就是分解和业务模块的划分，当我们在梳理业务流程的时候，流程的大的阶段往往就是关键的进行业务域分解和模块划分的关键点。比如上图，很容易想到对供应链业务拆分为招投标，采购，库存等几个大的业务模块。
　　在业务协同过程中往往还涉及到基础数据引用和准备，这些也需要在流程活动详细分析中给出，对于引用的基础数据往往又是一个共性的业务模块或外部接口点。
　　在进行完业务流程分析后，核心的业务活动，业务单据都清楚了，而这些刚好是我们形成需求建模的核心业务模块的基础。
　　一个需求模型往往包括如下关键内容：
　　从上图可以看到基于业务目标和业务流程驱动，在进行完流程分析后，我们最终是要识别出具体的业务用例，业务角色，业务对象，业务逻辑等关键业务要素，这些内容共同构成了一个完整的业务模型描述。
　　业务用例不是凭空产生的，业务用例往往是通过业务流程中的业务活动识别出来的。通用业务对象本身也不是孤立的，而是附着在具体的业务用例上。
　　当你完成需求分析后，基本已经解决了第一个问题，即我想要什么，我希望系统长什么样子，实现什么我需要的功能。但是还没有回答第二个问题，即我构建的模型如何来支撑我自己的想法。
　　用户可以不回答第二个问题，但是软件需求人员必须回答。
　　当我们通过需求分析和需求建模形成完整的业务模型的时候，这个时候业务模型中的用例，业务对象，规则等各个业务要素不应该是孤立的，而应该是高度协同的。只有高度集成和协同才能够完成一个完整的业务流程。
　　因此还需要去做一件事情，即：你分解完成的业务模块和业务用例之间，包括业务系统和外部系统之间，应该如何协同和集成，才能够完成最初梳理的端到端业务流程。
　　因此到这里再次体现了我前面谈到的两个重点，需求分析的重点是分解，是阐述清楚现实，讲明白我最终需要什么；而需求建模的重点是抽象和模型化，是自我论证构建的模型，通过模型组件间的协同，能够很好地支撑业务实现。
　　当把以上两点都做到的时候，软件需求的核心也就做到了。对于具体的UML用例分析，Axure的原型设计，UCD和交互设计，需求文档和用户故事等，都是方法和工具，不是核心。
　　软件需求的工作应该是以道驭术，而不是执迷于方法和工具。一个需求分析人员的核心能力是业务的抽象和建模能力，而不是简单地需求文档描述或原型设计能力。如何做好一名软件需求分析师
　　用户需求是对现实世界的定义，而软件系统需求是现实到实现的第一层抽象，即业务建模和软件系统用例建模。在原来的软件工程里面我们更多谈到的一个词是系统分析员，我现在将其拆分为了软件需求BA和系统架构SA两个角色。而实际上一个真正优秀的软件需求人员必须具备两方面的能力。
　　从软件需求在整个软件生命周期中的定位来看，其上接业务，下接设计和技术。从这个概念上来讲软件需求人员必须具备业务和技术两个方面的能力。
　　对于业务，首先要解决的是对业务的理解，然后才是在理解后业务的形式化表达和业务建模能力。而对业务如何理解，最核心的仍然是顶层的流程建模和分析能力，底层的业务活动和规则清晰的描述能力。在这里里面涉及到流程梳理和定义能力，业务单据和对象的抽取和定义能力，业务规则的清晰阐述能力，和流程配套的相关的岗位角色，交互等描述能力。要知道在这块往往并不需要太多的IT背景和软件工程的知识，更多的是对业务的熟悉，对流程管理和分析方法的了解。
　　第二个层面往往会过渡到系统软件需求层面的内容，在这里我们更加强调的是类似面向对象的用例分析和建模的方法，这包含了业务用例和系统用例分析和建模，是一种很好的形式化的方式来定义和描述业务的方法。包括从流程分析转入到用例，单个具体的用例分析和建模，每个用例详细的基本流，扩展流，业务规则，参与角色，界面原型，业务对象和对象属性等各个方面内容的描述，要知道我们做用例建模的目的是能够按用例驱动的核心，平滑地转入到架构设计中去，因此用例分析建模已经不是简单的描述现实世界的问题，已经涉及到业务或用户需求到系统需求的第一层抽象转换。
　　要做好需求的第二步的事情，那么单纯的只有业务背景就不足够的，必须还具备相应的IT和软件工程的技术背景。这个背景往往并不是说要做过多久的软件设计开发，但是只是是做过，通过软件开发你能够很清楚的知道一个软件从需求调研和分析开始，最终是如何形成一个软件系统的。这个背景知识可以更加方便我们去考虑用例建模，去认识到为何要采用这种方式去用例建模，真正理解用例中每个描述点如何影响到最终业务系统的实现。
　　软件需求人员需要具备技术背景知识
　　没有技术背景很难真正成为一个优秀的软件需求分析师，最多也就是一个业务需求分析师。
　　要知道，当你进行用户需求调研后，往往收集到的都是一个个的用户需求点，而一个软件需求分析员要做的是最终将这些需求实现为一个完整的业务系统。这里面就涉及到业务模块的划分，模块间的分析，需求层面的复用能力分析，各种性能，可靠性，安全等非功能性需求。这些更加已经是一个完全的系统分析方面的内容，或者说软件需求已经会兼顾部分软件架构设计的内容。
　　因此作为一个软件需求人员更加需要去了解业务组件化，服务化，软件模块集成，复用等方面的技术内容。也需要去了解涉及到UCD，交互设计方面的内容，这些都是形成一个高质量的软件业务系统的重要输入。
　　一个优秀的软件需求人员既不应该因为具备技术和开发背景而导致在需求分析和建模中的各种程序员思维，也不应该完全抛弃技术单纯的去描述业务不管实现的难易度。软件需求人员衔接了最终用户和内部的设计开发，是两者之间重要的沟通和协同桥梁。各种沟通和人际关系处理技巧，各种软技能的要求更是必不可少的，在此不再展开去描述。
　　一个优秀的软件需求人员不存在是否能做新领域的软件需求的问题，因为最终真正有用的是需求分析方法论和模式，去理解和熟悉业务和快速形式化描述和建模的方法，有不断的实践总结出来的快速理解业务的能力。
　　欢迎关注人月聊IT分享数字化转型，企业架构规划，云原生，思维和个人成长类文章。个人公众号何明璐，可以搜索关注，文章每周一，三，五定期更新。