13,190
社区成员
发帖
与我相关
我的任务
分享需求分析的使命和方法（2006-12-27完成内容）
论坛有字数限制。更多内容，请访问我的博客：http://blog.csdn.net/aafshzj/
好久没有更新博客了。说实话，负罪感挺强。今天脑子被某个问题卡住了，暂时懒得深究。想想，不如写点文章，当作自己的休憩和对各位殷殷期待的答谢。
需求分析是个老话题了。从混混沌沌到人人重视，一些情况已经有了明显的变化。然而中国软件项目的成功率，似乎并没有特别大的提升。关键在于：从思想上重视到实践中掌握，从夸夸其谈到得其要领，还有很大的距离。曾经给某大学软件学院的学生上过一堂课。课本身固然非常成功，但是从一个侧面，我也看到软件学院的学生们对来自实践的一手知识、实践细节、具体考量等的了解渴求。简单地照本宣科，对工程性的人员来说，没有任何价值。大家想知道的是：做什么？怎么做？如何去做？什么时候这样做？什么时候不这样做？如何又是如何？如何判断什么时候是某个“什么时候”？如此穷究下去，直到所有问题与个人的基本经验和尝试建立起由个人基本经验和尝试可以连接起来的清晰联系。
那么在需求分析的实战中，要注意什么呢？个人感觉，至少要注意这样几个方面：
1）对变化是拥抱还是拒绝？还是半推半就？
2）需求分析是否关注细节，关注哪些细节？
3）需求分析能保证项目的成功吗？
首先看看变化。这个世界目前处于迅速变化的时代。尤其是中国，从历史尺度的眼光来看，简直就是在爆炸。这种节奏是否可以长期维持，是可以好好打几个大大的问号的。但是，只要目前我们所在时空的时间箭头没有改变，人类“短期”的发展模式没有改变，这种“局部时间”的小“社会时空”继续在一个更大规模的涨落量上表现出单边的快速涨升还会维持一段时间。那么，作为这种局面下的系统和软件开发人员，如何面对变化，确实是一个值得思考的问题。实际上，关于这个问题的“正确答案”早就有了，但是正确答案要转变成正确实践，就不是那么容易和简单。时间的最大特点就是，有太多的指标和理论模型纠缠在一起，主要挑战就是判断和权衡。实践的成功一定来自判断和权衡的总体正确，而不是理论的孰优孰劣。
“对变化是拥抱还是拒绝？还是半推半就？”对于这个问题，我的回答是坚决地“半推半就”。变化有很多种，有因为不深入的了解今日以为这样明日发现其实是那样的“变化”（A）；有因为歧义或者过分依赖术语/常用语而不深究引起直到当某个词汇被澄清才让你发现的“变化”（B）；有因为外部环境发生变化，企业迅速跟进而引起的变化（C）；还有因为领导换人，不管有理无理都要标新立异而引起的变化（D）。
需求分析过程要尽可能避免A、B两类问题。出现这两类问题的时候，原因看起来是双方面的，但一般来说主要责任在于需求分析人员。因为需求分析的一个基本原则就是不要迷信术语，要讲业务流程和业务数据展开到业务层面的最细节。需求分析人员必须时刻注意对方的眼睛，发现其中的茫然、不解和困惑，而不是简单地将对方的点头和“嗯哦”当作是赞同。需求分析人员必须对不同的细节重要性有清醒的认识：细节作为一个概念确实非常重要，但是每一个现实的细节（细节的实例）并不都是一样重要的。如果对细节的重要性不能产生准确的判断和清醒地认识，不管在你心目中，需求获取和分析居于如何重要的地位，要得到令人满意的需求获取和分析结果都是非常困难的。因为无论你怎么脸皮厚，用户也没有时间听你把所有话题展开到最细微处。因此，辨别细节重要性能力就具有格外重要的意义。工程就是如此：你永远是在有限的空间、有限的时间、有限的资源下通过权衡解决有限的问题。只有分得清轻重，你才能取得成功。
对于C类问题，我们能做的是：具备一定的预见性。这又是一个需要权衡的问题。预见性过大，成本上升很好，预见性太小，面对变化时，哪怕是一些合乎道理、合乎规律的变化，也会导致巨大的开发成本。这种成本我们当然可以也应当要求用户承担。但是如果用户可以得到更好的服务呢？如果有人可以提供更有预见性的产品呢？用户的产品选型、项目开发其实也是一项工程，用户也是在诸多因素、诸多条件下权衡。只有善用权衡，才可能成功。只有拥抱竞争，才可能进步。因此，我的观点是，C类问题成本应由用户承担，但是对于一些“明显”的变化趋势，需求分析人员应该有预见性。开发人员应该通过预留接口和参数化等方式，对可预见的变化予以抽象化，并将区别抽象化为模型的高度一致和参数的设置不同。广义的，接口可以被看作一种参数化的行为，是将接口的外在表现抽象为高度一致的模型，而将接口的实现区隔出去的一种努力。对于C类问题，如果对于一些明显可以预见的变化没有充分准备，从而导致开发成本的上升，主要责任在于需求分析人员。
D类问题比较特殊，但是在我们这个极具特色的国家，还是挺常见的。对待此类问题，除了做好人事信息的收集工作和“危机”处理工作之外，就只有常常祈祷了。当然如果拥有结构超好，在一定领域内具有很高可塑性的框架或平台是会有裨益的。但即便如此，又有哪个系统能够自由到象不同人的心中瞬间就能疯长的意识的草。
前面讲了很多。有些问题并没有展开，比如如何确定哪些细节是重要的细节，如何才能提前掌握业务可能发生的变化？问题的答案既可以是经验主义的，也可以是系统性的。对于我来说，二者兼而有之。经验是思想的根，思想是经验的脑。关于学、思、行的关系，孔夫子讲了很多，在这点上，我看孔夫子的说法至今仍是非常恰当而精到的。那么如何确定哪些细节是重要的细节，如何才能提前掌握业务可能发生的变化呢？答案是面向对象的思维方式。面向对象的思维方式，最大的特点就是把业务领域的事物和规律，而不是其它的什么，作为分析和设计系统的基础。一个人要做好需求分析工作，就必须强化训练自己用业务语言描述系统功能性要求和非功能性需求的能力，知道这种能力近乎成为本能。当然，业务语言和技术语言有时候并不是完全对立，二者有交集。这在描述一些业务流程和业务数据的细节时尤其明显。实际上很多词汇与其说是技术词汇，不如说细节描述词汇。比如我们描述系统交互过程（这是系统需求分析的重点）时需要对流程中涉及的数据和信息的组成进行明渠的定义和说明：“用户需要输入订购数量、交货地址信息，订购数量是一个文本，长度可能有所限制”。
......
论坛有字数限制。更多内容，请访问我的博客：http://blog.csdn.net/aafshzj/
好久没有更新博客了。说实话，负罪感挺强。今天脑子被某个问题卡住了，暂时懒得深究。想想，不如写点文章，当作自己的休憩和对各位殷殷期待的答谢。
需求分析是个老话题了。从混混沌沌到人人重视，一些情况已经有了明显的变化。然而中国软件项目的成功率，似乎并没有特别大的提升。关键在于：从思想上重视到实践中掌握，从夸夸其谈到得其要领，还有很大的距离。曾经给某大学软件学院的学生上过一堂课。课本身固然非常成功，但是从一个侧面，我也看到软件学院的学生们对来自实践的一手知识、实践细节、具体考量等的了解渴求。简单地照本宣科，对工程性的人员来说，没有任何价值。大家想知道的是：做什么？怎么做？如何去做？什么时候这样做？什么时候不这样做？如何又是如何？如何判断什么时候是某个“什么时候”？如此穷究下去，直到所有问题与个人的基本经验和尝试建立起由个人基本经验和尝试可以连接起来的清晰联系。
那么在需求分析的实战中，要注意什么呢？个人感觉，至少要注意这样几个方面：
1）对变化是拥抱还是拒绝？还是半推半就？
2）需求分析是否关注细节，关注哪些细节？
3）需求分析能保证项目的成功吗？
首先看看变化。这个世界目前处于迅速变化的时代。尤其是中国，从历史尺度的眼光来看，简直就是在爆炸。这种节奏是否可以长期维持，是可以好好打几个大大的问号的。但是，只要目前我们所在时空的时间箭头没有改变，人类“短期”的发展模式没有改变，这种“局部时间”的小“社会时空”继续在一个更大规模的涨落量上表现出单边的快速涨升还会维持一段时间。那么，作为这种局面下的系统和软件开发人员，如何面对变化，确实是一个值得思考的问题。实际上，关于这个问题的“正确答案”早就有了，但是正确答案要转变成正确实践，就不是那么容易和简单。时间的最大特点就是，有太多的指标和理论模型纠缠在一起，主要挑战就是判断和权衡。实践的成功一定来自判断和权衡的总体正确，而不是理论的孰优孰劣。
“对变化是拥抱还是拒绝？还是半推半就？”对于这个问题，我的回答是坚决地“半推半就”。变化有很多种，有因为不深入的了解今日以为这样明日发现其实是那样的“变化”（A）；有因为歧义或者过分依赖术语/常用语而不深究引起直到当某个词汇被澄清才让你发现的“变化”（B）；有因为外部环境发生变化，企业迅速跟进而引起的变化（C）；还有因为领导换人，不管有理无理都要标新立异而引起的变化（D）。
需求分析过程要尽可能避免A、B两类问题。出现这两类问题的时候，原因看起来是双方面的，但一般来说主要责任在于需求分析人员。因为需求分析的一个基本原则就是不要迷信术语，要讲业务流程和业务数据展开到业务层面的最细节。需求分析人员必须时刻注意对方的眼睛，发现其中的茫然、不解和困惑，而不是简单地将对方的点头和“嗯哦”当作是赞同。需求分析人员必须对不同的细节重要性有清醒的认识：细节作为一个概念确实非常重要，但是每一个现实的细节（细节的实例）并不都是一样重要的。如果对细节的重要性不能产生准确的判断和清醒地认识，不管在你心目中，需求获取和分析居于如何重要的地位，要得到令人满意的需求获取和分析结果都是非常困难的。因为无论你怎么脸皮厚，用户也没有时间听你把所有话题展开到最细微处。因此，辨别细节重要性能力就具有格外重要的意义。工程就是如此：你永远是在有限的空间、有限的时间、有限的资源下通过权衡解决有限的问题。只有分得清轻重，你才能取得成功。
对于C类问题，我们能做的是：具备一定的预见性。这又是一个需要权衡的问题。预见性过大，成本上升很好，预见性太小，面对变化时，哪怕是一些合乎道理、合乎规律的变化，也会导致巨大的开发成本。这种成本我们当然可以也应当要求用户承担。但是如果用户可以得到更好的服务呢？如果有人可以提供更有预见性的产品呢？用户的产品选型、项目开发其实也是一项工程，用户也是在诸多因素、诸多条件下权衡。只有善用权衡，才可能成功。只有拥抱竞争，才可能进步。因此，我的观点是，C类问题成本应由用户承担，但是对于一些“明显”的变化趋势，需求分析人员应该有预见性。开发人员应该通过预留接口和参数化等方式，对可预见的变化予以抽象化，并将区别抽象化为模型的高度一致和参数的设置不同。广义的，接口可以被看作一种参数化的行为，是将接口的外在表现抽象为高度一致的模型，而将接口的实现区隔出去的一种努力。对于C类问题，如果对于一些明显可以预见的变化没有充分准备，从而导致开发成本的上升，主要责任在于需求分析人员。
D类问题比较特殊，但是在我们这个极具特色的国家，还是挺常见的。对待此类问题，除了做好人事信息的收集工作和“危机”处理工作之外，就只有常常祈祷了。当然如果拥有结构超好，在一定领域内具有很高可塑性的框架或平台是会有裨益的。但即便如此，又有哪个系统能够自由到象不同人的心中瞬间就能疯长的意识的草。
前面讲了很多。有些问题并没有展开，比如如何确定哪些细节是重要的细节，如何才能提前掌握业务可能发生的变化？问题的答案既可以是经验主义的，也可以是系统性的。对于我来说，二者兼而有之。经验是思想的根，思想是经验的脑。关于学、思、行的关系，孔夫子讲了很多，在这点上，我看孔夫子的说法至今仍是非常恰当而精到的。那么如何确定哪些细节是重要的细节，如何才能提前掌握业务可能发生的变化呢？答案是面向对象的思维方式。面向对象的思维方式，最大的特点就是把业务领域的事物和规律，而不是其它的什么，作为分析和设计系统的基础。一个人要做好需求分析工作，就必须强化训练自己用业务语言描述系统功能性要求和非功能性需求的能力，知道这种能力近乎成为本能。当然，业务语言和技术语言有时候并不是完全对立，二者有交集。这在描述一些业务流程和业务数据的细节时尤其明显。实际上很多词汇与其说是技术词汇，不如说细节描述词汇。比如我们描述系统交互过程（这是系统需求分析的重点）时需要对流程中涉及的数据和信息的组成进行明渠的定义和说明：“用户需要输入订购数量、交货地址信息，订购数量是一个文本，长度可能有所限制”。
......
论坛有字数限制。更多内容，请访问我的博客：http://blog.csdn.net/aafshzj/
...全文
请发表友善的回复…
发表回复
aafshzj 2007-03-14
- 打赏
- 举报
踹起来
aafshzj 2007-02-01
- 打赏
- 举报
zaiding
aafshzj 2007-01-20
- 打赏
- 举报
yuwen朋友，我在blog中回答了你的问题：
http://blog.csdn.net/aafshzj/archive/2007/01/20/1488703.aspx
http://blog.csdn.net/aafshzj/archive/2007/01/20/1488703.aspx
yuwen16 2007-01-18
- 打赏
- 举报
另外，小弟对上下文的概念不是很明白，不过大哥的存储上下文是明白了，
最近老看到上下文的东西，搞不清楚什么东西，大哥有没接触过？
最近老看到上下文的东西，搞不清楚什么东西，大哥有没接触过？
yuwen16 2007-01-18
- 打赏
- 举报
楼主，我一直在关心您的blog，想请问下，这几个技术点
1.如何去找全局id的对象？将一个对象存到hashtable中(guid,obj)?然后...?
2.对于hibernate是用了两级缓存的概念来做。请问您的缓存机制如何？能否详细指点？
3.特别是缓存同步，如何实现？
4.对于关系映射，多对多的处理如何？
5.对于agileobjectex与agileobject区别在于agileobjectex可以干预存储时或者loading时的动作，能否举例说明下什么时候需要干预？
小弟好多好多疑问，想请教，可否指点一二，我email为lan0821@gzemail.cn，上次问过您要测试代码和测试问题的，可惜现在测试依然不通。期待写些关于架构设计方面的文章。
谢谢了
1.如何去找全局id的对象？将一个对象存到hashtable中(guid,obj)?然后...?
2.对于hibernate是用了两级缓存的概念来做。请问您的缓存机制如何？能否详细指点？
3.特别是缓存同步，如何实现？
4.对于关系映射，多对多的处理如何？
5.对于agileobjectex与agileobject区别在于agileobjectex可以干预存储时或者loading时的动作，能否举例说明下什么时候需要干预？
小弟好多好多疑问，想请教，可否指点一二，我email为lan0821@gzemail.cn，上次问过您要测试代码和测试问题的，可惜现在测试依然不通。期待写些关于架构设计方面的文章。
谢谢了
aafshzj 2007-01-16
- 打赏
- 举报
ding
