软件需求、分析&设计的讨论（之一）

[Leo]

【 节选自QQ群——架构师联盟论坛的讨论记录 2008年10月30日 】

红叶(Leo)(38800226)12:13:43
最近在看李小龙传奇，从中悟出一点东东：功夫与做软件一样，不要去刻意区分某门某派，
某种拳术好，某种拳术差，广纳百家之长，因地制宜，为我所用。无论是面向对象也好，
面向过程也罢，也无论是RUP也好，XP也罢，更无论是JAVA也好，.Net也罢，C++/C也罢，
都有优秀的地方和擅长的区间，拿来为我所用，创自己的“截拳道”，更能促进技术的发展
与交汇，有利于客户，有利于开发者，也有利于投资商。以前有做面向对象软件的人看不
起做面向过程软件的人，有用java的人看不起做VB的人，有JAVA的程序员与.net程序的针
锋相对的贬低。这些从解决客户问题和发展技术角度来说都是毫无意义的，也是浪费时间的。

风在吹(94524029)12:26:25
哈哈，这些技术还直接些哦

风在吹(94524029)12:26:35
要是谈分析技术可能更让人琢磨

红叶(Leo)(38800226)12:33:40
其实软件界也是一个“江湖”，也有很多门派之分，这种门派隔阂了多少的技术交流、学习
和借鉴。无论是国内还是国外，派别之争从未断过，以前有建模语言的争论，现在有开发
过程的对立（最典型的是XP与RUP的对立）。国内还有程序员之间的派系之分，如：有很
多做JAVA的程序就不愿意深入了解.net的技术，做.net的程序也不愿意深入学习JAVA的长
处，总在诋毁对方的不足。

风在吹(94524029)12:34:18
呵呵，各位研究过需求分析技术没有？

红叶(Leo)(38800226)12:35:03
“风在吹”，你想谈哪些需求分析技术？

风在吹(94524029)12:35:18
用例需求的分析技术
用例驱动

红叶(Leo)(38800226)12:35:38
嗯～你有哪些心得？疑问？

风在吹(94524029)12:36:34
这是一个理论上很优秀的分析技术
但具体到功能需求的分析，就显得力不从心了
而且，我目前还没有发现很好的需求检测和测试方法

红叶(Leo)(38800226)12:36:55
怎么这样认为呢？

风在吹(94524029)12:37:09
是感受

红叶(Leo)(38800226)12:37:17
说来听听

风在吹(94524029)12:37:28
做到后来了，基本用原型法了
原来用用例分析的东西很多都更改了

红叶(Leo)(38800226)12:37:51
前面怎么做？后来为什么不用？

风在吹(94524029)12:37:55
而且，最要命的是用户不懂

红叶(Leo)(38800226)12:38:21
哈哈...这对很多人有同感，但这不是用户的问题，是分析人员的问题

风在吹(94524029)12:38:46
为什么？是我们的沟通和讲解能力不够？
还是自己的技术分析能力不够？

红叶(Leo)(38800226)12:38:54
你认为中国话应该对你不成问题吧？

风在吹(94524029)12:39:18
继续

红叶(Leo)(38800226)12:39:43
如果我用中国话跟你讲周易八卦，你听懂吗？

风在吹(94524029)12:40:10
你说的这个道理我想每个分析人员都懂
可是真正实践起来不容易

红叶(Leo)(38800226)12:41:28
所以，道理是一样的。用例其实是一个很容易弄懂的表示法，即便是客户也能懂——除非用
户连自己如何使用电脑都不知道——这样你也不用给他做软件了——先给他普及一下电脑知识吧。

风在吹(94524029)12:41:42
分析人员不懂业务，用户不懂软件

风在吹(94524029)12:42:27
我说是跟用户交流的

红叶(Leo)(38800226)12:44:43
我们很多分析人员在用用例来描述客户需求的时候，其实并没有用客户所熟知的术语或概念
来表示（分析员有点直接用增删改来描述），这些术语和概念当然不能让客户弄明白，另外，
描述用例的流程，也就是用例规约的时候很罗嗦、繁琐，并且不是站在业务角度来描述，连
做了多年的分析设计的人都不一定看懂，也不想去看。

风在吹(94524029)12:45:30
你说的这种情况其实是程序员的思想没有转过来
没有改变思想，自然会出现这种情况
他们往往首先想到的是实现，如何实现
作为分析人员，要从业务，从系统的角度去考虑
如何实现，那根本不是你应该考虑的问题
个人观点，程序员出身的，交流沟通能力不强的人做分析人员很不合适

红叶(Leo)(38800226)12:49:21
其实我已经给你指出了其中的玄机用例分析技术不是万能，也不是关键，关键的是分析人员
对业务是否能熟知和掌握，同时具有把需求模型化和客户化的能力，这就是要在系统和客户
之间架起一座沟通的桥梁。所以我说你所述的问题不是客户的问题，而是分析人员的问题。

红叶(Leo)(38800226)12:50:32
休息一会

Cody(21851258)12:50:56
继续啊，在等着看精辟的描述呢

风在吹(94524029)12:51:34
从业务人员中培养分析员比从程序员中培养分析员要容易得多

红叶(Leo)(38800226)12:51:49
风在吹(94524029) 12:51:34从业务人员中培养分析员比从程序员中培养分析员要容易得多
同意

红叶(Leo)(38800226)12:52:10
:)

Cody(21851258)12:52:40
风在吹，如果让业务人员深刻的理解那些条条框框的技术细节呢？

风在吹(94524029)13:01:32
分析人员没有必要理解技术细节

风在吹(94524029)13:01:45
那不是分析人员的工作

Cody(21851258)13:02:20
那分析人员的能力岂不是和业务人员一样了？who来做桥梁把前后串连起来？

风在吹(94524029)13:02:27
什么数据库设计啊，程序设计啊
这都不是分析人员的工作
业务人员需要培训才能成为分析人员
分析人员没必要知道程序如何写，数据库如何设计
这些都没有必要
他只需要知道问题是什么？怎么解决就可以了
至于如何实现，这不是他的事
这是技术人员要讨论的问题
架构师不是分析员
各人关注点不同
个人觉得分析员有点类似于商人

Cody(21851258)13:13:23
睡觉啦

风在吹(94524029)13:25:49
我睡醒了

红叶(Leo)(38800226)13:30:59
刚起“椅子”，一觉醒来，风在吹就已发表了这么多高见，很好呀！

红叶(Leo)(38800226)13:37:05
我经常跟我的分析员说：你只有把客户的想法和潜在需求弄清楚了，能把系统（可能是虚
拟的）如何使用的过程给客户描述清楚，客户才能看懂你写的东西，无论这个东西是用叫“
用例技术”来做的，还是叫别的什么东东来做的。客户只有在“看到”或“想到”他如何使用你
开发的系统，才能更能深入理解和告诉你他需要的是什么，不需要什么。另外，我还要去
我的分析人员必须给出用例与参与者界面原型，这样才能帮助客户理解系统和针对系统界
面原型提出他们的想法和修改意见。
另外，我还要求我的分析人员必须给出用例与参与者之间的界面原型，这样才能帮助客户
理解系统和针对系统界面原型提出他们的想法和修改意见。
这里所说的“分析员”应该是“需求分析员”，不是软考里所指的“系统分析员”或“系统分析师”。