需求和建模

“建模就是抽取名词和动词”

今天的内容关于需求和建模，相信很多小伙伴们都经历过相关的场景。也是开发过程中比较头疼的一部分，今天就来聊一聊它吧。

本文适合以下小伙伴阅读：

• 开发新功能不知从何下手
• 做了很多年开发，还是没有一套固定套路做功能设计

好了，正文开始！

需求

做开发的小伙伴们应该都接到过不少需求了。

这里不讲需求的定义了，我也讲不清楚，粘网上的定义也啰嗦，就随便聊聊吧。

这里简化一下，只聊两种角色（软件项目中角色很多很多）：开发人员和需求人员。

假定的工作流程：

只简单假设

• 开发人员接需求，做功能
• 需求人员接收功能，提供需求

那来逐个分析：

开发人员视角

对开发人员来说当然期望有”好“的需求。

那啥是好呢？我觉得是对开发人员好的需求应该是明确、清晰的。那需求中明确提出模型就更好了。

需求人员视角

需求人员希望能更快地提需求（方便去做主要工作），更快地获得更好的功能。

对于提需求这点，很多需求人员说的都不标准，有时甚至文字描述都很少。

其实也难为他们，工作领域不同，思维习惯也不一样，难免的。

而且对于他们来说，提需求不是主要的工作内容，只是额外开个小差，也不需要多精进这方面的能力，所以花一小部分时间弄一下也就是了。

所以一般出的需求说明书都是不准确、非模型化的。

说到这里可能有人发现了，不管是开发人员还是需求人员，都不想做“建立模型”这块工作。

好像都想把这块工作推出去（笑哭）。

但软件的编写和运行却又少不了准确清晰的模型

所以这时，需求人员和开发人员都会很难过：

• 需求人员总是得不到想要的功能，且多付出很多成本（时间和经济）
• 开发人员的工时变长，且返工率变高

那要怎么办呢？

肯定是有人把这块的职责担起来呀。需求人员我们无法控制，只能我们开发人员做建模的工作了。

但其实，建模的工作看起来也挺酷的，学会它也很好啊！

那在讲建模之前，先聊一下我对需求和模型间关系的理解吧，看完可以更好地理解建模过程。

现实世界、需求、模型的关系

说一下我对需求的前后关键概念的理解：

现实世界、需求人员眼中的业务模型、需求、软件模型(1、2、3)

现实世界：

现实世界是一个比较混乱的东西，没有固定的形状，描述也难，类比成不规则的线条。

需求人员眼中的业务模型（具化为两个业务点）：

需求人员眼中的业务模型有两层：

• 内层是清晰的，表示需求人员自己明确知道的业务逻辑
• 外层是模糊的，表示需求人员自己不太知道，或者不太明确的业务逻辑。

需求那边也不一定知道所有的逻辑（没人能全知全能嘛），所以总有些东西是模糊的。

总体类比成上图，有清晰的部分，也有模糊的部分。​

需求：

图中位于上方的、线状的是文字描述的类比图。
图中位于下方的、几何图形的是模型描述的类比图。

需求信息一定会比真实世界的信息少，缺少细节。而且，需求人员也不太可能把所有自己已知的东西都正确清晰地表达出来。

所以对于文字描述，类比成线状的图形，且与比之前的真实世界的图形更平滑（相当于信息少了），且波峰波谷不完全一致（象征着与现实世界的差距）。

而且，以此为依据的建模，也肯定与真实的业务模型相悖。

所以，为了方便多视角观察，图中的下方图形则给出了另一个关于模型的视角：

虚线部分表示需求人员自己明确的自己的业务模型，而实线部分表示的是软件建模时的模型。

实线框大部分在虚线框内，小部分出了实线框。表示因为信息的丢失与错误，大部分需求能满足，但小部分需求满足不了，也可能出现需求人员非预期的问题。

软件模型：

我将软件模型分为三个阶段，下面分别介绍：

阶段一：软件早期模型

此阶段的软件模型与需求人员脑中的模型并不十分匹配，但有一定匹配度，也能完成一些需求人员要求的业务操作。但对于使用者来说，总是有哪些地方用着不舒服，有些问题甚至会拉低业务效率。

阶段二：软件成熟期模型

此阶段的软件模型已经完全覆盖需求人员脑中的模型。此时需求人员对功能没什么建议，软件也可以完整地支撑业务。

阶段三：软件完美期模型

此阶段的软件模型已经已经与需求人员的脑中混乱的知识边界重合。说明此阶段已经由开发人员（或建模人员）与需求人员沟通多次，开发出了需求人员的潜在需求和业务逻辑，使需求人员的需求更加符合现实世界。

此模型是理想状态的模型，需要多方共同努力才能完成建立。

建模

软件其实是对现实的模拟和抽象。

需求中，一定有一些文本描述（当然有图什么的更好了）。

所以在不考虑极限性能的情况下，设计不需多考虑计算机相关的内容，只需要反应现实的模型就可以了。

下面举例说明，如何从需求中抽出模型

案例解析：贪吃蛇小游戏

需求人员：

• 我要做一个贪吃蛇小游戏
• 蛇能吃东西，吃了东西就会变长

开发人员（建模人员）【抽取动名词】：

• 名词：我、蛇、东西
• 动词：吃、变长

分不清动名词的看这里：
简单来说就是：动词是动作，名词是东西。

开发人员（建模人员）【思考】：“我”这个概念好像没用，删掉。“东西”这个概念好像不对，应该是“食物”。

开发人员（建模人员）【动名词回顾】：

• 名词：蛇、食物
• 动词：吃、变长

开发人员（建模人员）【思考】：按照面向对象的思想，“吃”和“变长”应该都是蛇的动作。那现在蛇的动作关联上了。需求里提到了，”吃“后会“变长”，可是什么时候“吃”呢？

开发人员（建模人员）【沟通】：蛇吃东西，这里的东西是食物吗？

需求人员【沟通】：是的，是食物。

开发人员（建模人员）【沟通】：那”吃“这个行为发生在什么时候？或者描述一下怎么“吃”的？

需求人员【沟通】：就是蛇会一下一下地走，然后碰到了东西就会吃掉。

开发人员（建模人员）【思考】：又用了“东西”这个词（汗）。直接替换成“食物”。

开发人员（建模人员）【思考】：出现了两个新动词：“走”和“碰”

开发人员（建模人员）【沟通】：也就是说，蛇会“走”，我理解成“移动”没问题吧？

需求人员【沟通】：当然了，要不然是啥

开发人员（建模人员）【沟通】：那“碰”是什么意思？应该是“蛇”来“碰”东西吧？那具体来说就是，“蛇”能碰什么？

需求人员【沟通】：就是能碰墙，碰到墙就死了。对了，碰到身体也会死。还有，刚刚说的吃，碰到食物就会吃掉。

开发人员（建模人员）【思考】：又多了两个新名词：“墙”、“身体”。然后明确了一个细节：“碰”到食物就会“吃”掉。还有一个动词“死”。

开发人员（建模人员）【思考】：而且，提到了“身体”，那它应该代表“蛇身”。那是不是还有蛇头呢？

开发人员（建模人员）【沟通】：我看提到了“身体”，我理解是指的“蛇身”吧？那是不是还有“蛇头”？

需求人员【沟通】：当然是了，都是。有蛇头，蛇头来吃东西嘛。

开发人员（建模人员）【思考】：那就是”蛇身“、”蛇头“。蛇头“碰”到“食物”触发“吃”动作。”蛇头““碰”到“蛇身”或“墙”触发“死”动作。

开发人员（建模人员）【动名词回顾】：

• 名词：蛇、墙、蛇身、蛇头、食物
• 动词：移动、碰、吃、变长、死

开发人员（建模人员）【机制回顾】：

• “蛇头“”碰”到“食物”触发“吃”动作
• ”蛇头““碰”到“蛇身”触发“死”动作
• “吃”动作会触发“变长”动作

开发人员（建模人员）【思考】：那“移动”怎么办？上面提到了一步一步地”移动“。

开发人员（建模人员）【沟通】：我刚刚想了一下，没太明确“移动”是怎么移动的？我记得说的是“一步一步地”移动。是那样类似一秒一次这种吗？

需求人员【沟通】：对，差不太多的。就是一下一下地动嘛。然后玩家用键盘按上下左右，它就往哪走，吃东西去了。

开发人员（建模人员）【思考】：上下左右？那看来是方向，确认一下。

开发人员（建模人员）【沟通】：那“上下左右”说的是方向是吧？就是说蛇是根据玩家的输入，会向不同方向移动。

需求人员【沟通】：对对对，就是这样。

开发人员（建模人员）【思考】：那又多了一个名词：“方向”

开发人员（建模人员）【动名词回顾】：

• 名词：蛇、墙、蛇身、蛇头、食物、方向
• 动词：移动、碰、吃、变长、死

开发人员（建模人员）【机制回顾】：

• “蛇头“”碰”到“食物”触发“吃”动作
• ”蛇头““碰”到“蛇身”或“墙”触发“死”动作
• “吃”动作会触发“变长”动作
• ”蛇“根据玩家的输入，改变“方向”
• “蛇”根据“方向”，一步一步地（周期触发）”移动“

开发人员（建模人员）【思考】：现在看起来机制暂时可以连接起来了，接下来做个小成本的demo给需求人员确认后再继续沟通吧。

开发人员（建模人员）【沟通】：ok，那我暂时没什么问题了，感谢您的配合。下次会做出demo继续沟通！

相信大家应该到现在也看出来了：上面的动词和名词分别对应面向对象编程（OOP:Object Oriented Programming）中的属性和方法。

上面基本的需求现在清晰多了，可以开启IDE，进行快乐地开发了！

小贴士：开发目标以机制作为目标，一个一个实现，这样就可以更好地量化开发进度了！

总结

通过文字需求建模的方法：

• 抽取动名词作为建模的开始
• 过程中通过互相沟通来完善模型和机制
• 确认机制初步完备后，为本轮建模的完成标识

可以上述通过一轮一轮的建模与迭代，逐步完善模型和程序。

内容还感兴趣吗？公众号中会有更多相关内容持续更新哦