业务流程不是需求

用了一下　感觉不错　确实更容易把思路哩清楚
有些东西用流程分析　就会变得复杂了　

这个度是很难把握的，尤其是当流程中的变化点有多个且又互相有冲突的时候，这个时候如果只在一个方向上考虑了灵活设计反而有可能陷入过度设计。

我的理解，过度设计是因为技术引导了开发过程，而实际上我们应该以业务为基础而不应该被技术牵着鼻子走。

灵活性需要以和客户的沟通结果为依据，当然不能说任何地方都要一味追求灵活性。比如，系统可能和外界的接口我们当然应该请客户确认，这个外部接口可能变化的可能性，此时就应该有一个灵活的设计了吧。

掌握某种技术不一定要在一次全用上吧,否则就是不切实际，纯粹的,酸腐的技术人员。

呵呵，技术领域有过度设计，业务领域一样可能有过度设计的。
客户（大多数情况是某个或者某几个用户代表）对未来的业务预测也并不是百分百正确的。

“过度设计”这个度你如何去把握？如何说一个设计是过度设计呢？
所以说软件设计是艺术不是技术的原因就在这里，你根本没办法知道什么时候过了度，大家都是靠感觉的。至少现在是这样。
我们没有办法去区分是否过度设计，但是我们可以估算一个设计是否能在资源要求下完成，所以，我认为设计只有合不合理，没有“过度”或者“不过度”的区别。

商业需求是该做什么，而业务流程是怎么做。再尚未调查清除该做什么的情况下，就去急怎么做，有点急功近利。将来必然发现有很多遗漏，通常是业务上的关联。

逻辑上没有问题，但是不符合客观事实，仅限于“能够完全正确获得真正需求”的理想条件下。

楼主的题目比较大，因此到了后头众人议论的范围似乎超越了楼主所要表达的范畴，我想能够表达楼主意思的是这么一种描述（我这里姑且妄自忖度）：业务流程不仅仅是需求.业务流程描述的是动态的需求链，我这里用“链”意思是它由静态的需求点加动态的业务行为点构成，如果把业务流程说成森林，那么静态的需求点和业务行为点就是树木，我们做软件系统的一种哲学就是化大为小，因为粒度越细越能看透被模仿物（被实现对象）的实际特性和行为，灵活性也越高，如果以粗粒度实现，由于看不透事物本源，那么做出的系统会离题，当用户需求变动大时，就无法满足变化，系统变得僵硬呆滞。楼主通过一个移动业务的典型例子，比较具体的指出，以业务流程去把握需求是不够的，需要透过业务流程，把握不变或则稳态的需求点，着重于这些点的关联与分析，这样才是需求收集和分析的正确方法和方向。

我也非常同意你们的观点，但是觉得你们说的是理想情况下的，也就是用户下了很大的决心打算根本解决一些问题，但是这样的情况又有多少呢？你不可能把系统优化的很完美，那样一些人该失业了，还会让你搞下去么？在中国就是这样。
    在某些情况下业务流程就是用户的需求的，也就是说有时只是简单的解放一下他们的劳动力，让领导，用户有时间干些别的，呵呵呵。。。
    我觉得咱们开发人员所说的需求是什么？其实就是用户的需要，让她满意了，他只想搞个简单的系统，你不能说，你们搞个类似ERP的大系统吧，让你们完全解放，第一，费用的问题，第二，人员安排的问题，说白了，还得要看人上茶水呀。
    我这只是说的中国的现状，顺便唠叨几句。