我说的不是0和1的事，是1和1的事。你说话有点自说自话，跟人讨论没有说清哪里赞同，哪里有分歧，这不是明晰的逻辑和表达方式。所以，且慢表扬自己。
我不知道你具体干什么，反正你这样的去分析业务逻辑会是个灾难。需求分析首先得会听和理解，然后把理解的客户视角的业务逻辑用开发者需要的规范方式表达，而不是要客户适应你的预设框架。
其中含糊的地方要弄清避免歧义，也要留下足够的灵活性，因为需求确实会变，或者对需求的表达和理解会变，这不可避免。限制需求变化是需要的，但是首先应该尽量理解需求，能尽量抽象，保留灵活性和适应性才是高级和低级架构设计的区别。

【 在 vkisiter 的大作中提到: 】
: 哈哈，我这类人碰电脑比较多的人比较简单，0就是0，1就是1，
: 如同写需求规划说明书一样，场景、流程、功能、接口、字段、业务规则、技术指标和约束条件等很多的要求必须明确，不能有岐义和曲解，要评审要确认，不然的话，就没有边界，流转给技术做完之后，客户就会再提这个没有结束，要求再继续免费的做下去。
: 同样，你知道你的文字给我的感觉是什么？是一个没有边界的描述，只凭意会，而每个人对此的理解可以衍生不同的理解，从我的职业习惯上来看，认为这是一个重大失误。
: ...................
--
FROM 221.216.147.*