程序也好，需求也罢等等，都是需要做设计的。
所以呢，开天辟地的说：从设计讲起
我认知的设计分为 ： 1：发明性设计（这种设计的出现意味着你是一个大佬了）
2：分配性设计（把现有问题分为若干模块一一实现或解决）实际上也有划分范围的意思
在设计的概念中没有绝对的对与错，只有好和相对不好；
再聊聊需求分析：
在对一个事物进行深入的了解时一定要看看前人对这个事物的定义，这里的定义是被客观证明过的。
在我看来做程序的核心就是服务客户，了解客户的行为动机，客户的行为动机可以由客户受众群体，环境，行为组成。
若把客户的行为动机了解清楚了那么就可以减少程序的改动。
以上都是站在一个纯理论性的角度去想，但实际生产才是分析需求到什么程度，或者把某个需求定义在某个范围的要素；
在这里就会做出抉择，需求范围的定义是绝对的只有对错没有好坏，如果范围模糊这会直接影响当前程序版本的体验；
ok 假设你为一个需求做到了一个明确的范围，被客户总结为一句话：
看红线部分其中动词为接下来需求的控制器，仔细想登录得有控制器没问题把，填是涉及到修改或增加的控制器，点击涉及到业务模块的控制器。有人看到这就会纳闷，当中明明还有些可以看出来的需求怎么不说，下面会讲的。
看蓝色部分这些名词显而易见这些会作为我们程序中的实体类。而程序大部分都是用来对这些实体类管理组成的
绿色部分就可理解为外部控制器 ，例如这个发送就是一个按钮；
这里用橙色圈起来的被称为隐性需求，这里包含了很多隐性需求 1：平台安全问题；2：平台权限问题; 3 客户个性化问题；
这其中的需求是没有明文的所以被称为隐性需求。
以上为对定义需求范围的分析理解；
下次会跟新一篇精确到功能的需求分析；