比如说需求如何传递给需求分析人员，机能设计（业务模型）怎么反馈给用户；比如说机能设计如何转换到程序设计，再转换到代码……
在这些过程中有哪些人员协作，通过什么样的载体，以什么样的机制进行信息传递……
对于不同的软件过程、不同的设计思想（结构化、面向对象），这些协作、载体、机制的变化……
虽然《RUP》里使用工作留对软件开发进行了研究，但是没有一条显著的信息流的线索，而且其中的制品（载体）全是uml的东西；《敏捷建模》列举了所有的建模技术，但是没有提供在各种软件过程中的运用。
很想能够总结出一些东西，奈何才疏学浅、经验不足，脑袋里始终一团浆糊@_@
希望各位施以援手，救人于水火之中 m(__)m
25 个解决方案
#1
我想知道你对软件开发过程中信息的定义
#2
终于有人关注了！！！
我说的信息的意思的是：
需求是用户提出来的原始信息。
它经过系统分析员的处理，变成的业务模型的形式，传递给程序设计人员、测试人员、文档人员，为别成为程序设计、测试用例、用户手册的形式。
而程序设计又传递给编码人员，成为代码的形式。
当然，对于不同的开发过程模型，还会有其他不同的中间形式。
在信息的传递过程中，不断地变换形式、加入附加内容。
如何保证信息传递的通畅、信息标准的唯一？这是我关注的问题。
这实际上是软件开发中的communication的问题。
communication不仅仅是口头上的交流，也包含书面的形式。
口头上的交流不是持久的，演示、讨论使用的草图也是一次性的。
必须要有一个唯一的、持久的文本形式的文档来保存当前已知的信息。
虽然代码是最终、最完备的设计，但是由于它过于细致，以至于让人“见木而不见森林”。
如何选择信息的保存格式？如何选择信息的保存时机？
这也是一个变化的问题。
比如一个小项目，分析、设计、开发、测试人员都做在一间小屋子里，那么很多中间文档都可以省略。出于维护的考虑，可能会保留一份模块关系图，一份模块接口说明，以及一份模块功能概要。
但是如果一个大项目，特别是跨项目组、跨公司的项目，就需要把与其他合作团队的接口文档做到非常详细。比如编码由别的公司负责，那么就需要提交十分详细的设计文档。
我也做过一些大大小小的项目，但数量不是很多，种类也不够丰富。
所以希望各位经验丰富的老大们能够提供一些案例，给我一些指导。
再拜！ m(__)m
我说的信息的意思的是：
需求是用户提出来的原始信息。
它经过系统分析员的处理，变成的业务模型的形式，传递给程序设计人员、测试人员、文档人员，为别成为程序设计、测试用例、用户手册的形式。
而程序设计又传递给编码人员，成为代码的形式。
当然，对于不同的开发过程模型，还会有其他不同的中间形式。
在信息的传递过程中，不断地变换形式、加入附加内容。
如何保证信息传递的通畅、信息标准的唯一？这是我关注的问题。
这实际上是软件开发中的communication的问题。
communication不仅仅是口头上的交流，也包含书面的形式。
口头上的交流不是持久的，演示、讨论使用的草图也是一次性的。
必须要有一个唯一的、持久的文本形式的文档来保存当前已知的信息。
虽然代码是最终、最完备的设计，但是由于它过于细致，以至于让人“见木而不见森林”。
如何选择信息的保存格式？如何选择信息的保存时机？
这也是一个变化的问题。
比如一个小项目，分析、设计、开发、测试人员都做在一间小屋子里，那么很多中间文档都可以省略。出于维护的考虑，可能会保留一份模块关系图，一份模块接口说明，以及一份模块功能概要。
但是如果一个大项目，特别是跨项目组、跨公司的项目，就需要把与其他合作团队的接口文档做到非常详细。比如编码由别的公司负责，那么就需要提交十分详细的设计文档。
我也做过一些大大小小的项目，但数量不是很多，种类也不够丰富。
所以希望各位经验丰富的老大们能够提供一些案例，给我一些指导。
再拜！ m(__)m
#3
或者应该叫做：“effective documentation in software developing”？
:)
:)
#4
软件工程的每个阶段,都要有相应的设计文件,即文件产品.
这些文件产品就是项目信息流的载体.
如:项目需求分析,总体设计,概要设计,详细设计等.
这些设计文件必须要标准化.
小组内部要有标准,软件企业自己要有标准,
进行联合开发或外包,设计文件就要符合行业标准.
大家按一种标准来协作,才能保证信息流没有差异的传递.
文档模版就是一种标准.
UML也是一种标准.
这些文件产品就是项目信息流的载体.
如:项目需求分析,总体设计,概要设计,详细设计等.
这些设计文件必须要标准化.
小组内部要有标准,软件企业自己要有标准,
进行联合开发或外包,设计文件就要符合行业标准.
大家按一种标准来协作,才能保证信息流没有差异的传递.
文档模版就是一种标准.
UML也是一种标准.
#5
谢谢版主指点!!
我现在的疑问正好是如何制定自己的标准。
:)
RUP提倡重量型文档，AP提倡轻量型文档。而在实践中，需要选择合适的文档。
面对各式各样的文档模板，如何做出选择？
我们首先必须明白信息如何流转，以及哪些信息是有效的、哪些信息是需要持久保存的。
开发过程中软件本身的信息流就已经很麻烦，再加上管理使用的信息流……
头晕了头晕了……
我现在的疑问正好是如何制定自己的标准。
:)
RUP提倡重量型文档，AP提倡轻量型文档。而在实践中，需要选择合适的文档。
面对各式各样的文档模板，如何做出选择？
我们首先必须明白信息如何流转，以及哪些信息是有效的、哪些信息是需要持久保存的。
开发过程中软件本身的信息流就已经很麻烦，再加上管理使用的信息流……
头晕了头晕了……
#6
抱歉，有些表述不清……
我说的“制定自己的标准”，
是说在项目中传输信息的标准，
也就是在什么时机、运用什么样的文档、使用什么样的方式来进行交流。
我说的“制定自己的标准”，
是说在项目中传输信息的标准，
也就是在什么时机、运用什么样的文档、使用什么样的方式来进行交流。
#7
首先请楼主莫怪,我问楼主信息的定义是怕引起交流二义性。
其实楼主对软件开发过程中的文档的重要性有相当的见解。“effective documentation”的定义十分精确，楼主烦恼的是在不同情况下，该使用那些信息（文档及其它开发工件）进行交流？楼主说的制定自己的标准，是不是在项目开发过程中根据项目的外在环境和内在环境的制定出一套信息交流的方式，使之达到“多一分则太赤,少一分则太白”的境界。
其实楼主对软件开发过程中的文档的重要性有相当的见解。“effective documentation”的定义十分精确，楼主烦恼的是在不同情况下，该使用那些信息（文档及其它开发工件）进行交流？楼主说的制定自己的标准，是不是在项目开发过程中根据项目的外在环境和内在环境的制定出一套信息交流的方式，使之达到“多一分则太赤,少一分则太白”的境界。
#8
开始做设计，以前做程序的，学习来了。
#9
《RUP》我有幸也看过，但是说RUP提倡重量型文档,我倒不这样认为。举个例子，RUP涉及的文档好比是对一个类的所有状态的描述，而我们对这个类的一次方法调用，不一定要遍历所有的状态。我们可以对RUP进行剪切，使之适应我们的项目开发。
RUP的“制品（载体）全是uml”实际也没有什么不妥，就象tj_dns(愉快的登山者 MVP)所说 “UML也是一种标准”，使用UML产生的各种图，就是我们要交流的信息，只有按照大家认同标准产生的信息，才能被大家理解和接受，就象许多跨国软件项目要求用英语写文档一样。
软件开发中的信息流转，并不是指“有一条显著的信息流的线索”，我觉得理解为工作流更妥当一些。可以看看工作流的三个要素：角色、相关数据、转移条件。软件开发过程中，对开发人员进行角色划分，这是大家所认同的。这样可以使工作分工明确，易于管理，使开发过程中产生的信息更有针对性；我们所书写的文档及其它工件可以看作软件开发过程中流转的信息；转移条件可以，看作是一次里程碑的结束。这样的理解可以使软件开发过程更具立体感、阶段性和层次性。
一己之见，还望指正。
RUP的“制品（载体）全是uml”实际也没有什么不妥，就象tj_dns(愉快的登山者 MVP)所说 “UML也是一种标准”，使用UML产生的各种图，就是我们要交流的信息，只有按照大家认同标准产生的信息，才能被大家理解和接受，就象许多跨国软件项目要求用英语写文档一样。
软件开发中的信息流转，并不是指“有一条显著的信息流的线索”，我觉得理解为工作流更妥当一些。可以看看工作流的三个要素：角色、相关数据、转移条件。软件开发过程中，对开发人员进行角色划分，这是大家所认同的。这样可以使工作分工明确，易于管理，使开发过程中产生的信息更有针对性；我们所书写的文档及其它工件可以看作软件开发过程中流转的信息；转移条件可以，看作是一次里程碑的结束。这样的理解可以使软件开发过程更具立体感、阶段性和层次性。
一己之见，还望指正。
#10
看了几天，也想了几天，但是还是没有想太明白。不过还是进来，给大家分享我的结果。
首先说到信息失真问题。这个问题早就被大家重视，并且做过很多努力解决的尝试。大家可以参考电梯问题历史。学术上的解决途径是使用形式化语言，但是实用性不强，也无法解决客户和开发者之间的交流问题。
另外一种就是多种文档、多侧面、多方法共同说明，这个是我们常用的方法。但是很容易被文档所误导。特别是不能保持文档同步的时候，情况就更糟糕。而使用机器手段可以保持同步，但是机器生产的文档，有迫于格式的束缚，无法表达书写者的思维意图。
其实如果我们看看电子领域怎么去解决失真问题的，对我们会有启发。你要做一个放大器，你首先可以使用模拟和数码两者选择。数码的放大可以做到完全不失真，但是数模模数转化的时候会失真。而往往我们不需要那么复杂，直接对模拟信号做放大就可以满足我们的要求。而这里有两个方法，一个是步骤很多，放大一次就做一个失真的修正。或者你干脆就选择最少的步骤，一次放大。这个时候你选择失真最小的配件，使用最简单的设计，你会得到最保真的品质。所以你会看到从NE5535导LT1028到今天的更强的运放。而后来大家发现使用火牛和电子管的效果虽然指标不好，但是听感好的多，于是有去追求灯。
软件中的信息其实一样，我们既然已经选择不使用形式化的方法，我们就应该明白不能保证其完全不失真。我们为了降低失真的危害，我们首先应该减少信息流转的步骤，追求信息尽快到达。而同时我们还可以使用辅助手段，比如文档，降低部分失真。但是辅助手段过多一样会带来失真。而同时我们也不要忘记形式化的优点，我们可以采取文档写作使用部分形式化的自然语言。比如我们可以采取实词原则，选择饰词明确原则，选择誓词责任人原则等等。例如说界面迅速作出反映，这显然不能明确说明究竟怎么叫迅速。而界面马上作出反映会好一点，但是马上还是不能明确修饰速度。而你直接说要在一秒内作出反映，就明白无误的告诉对付，速度的要求就是一秒。同样道理我们可以最反映作出逐步的明确含义的解释。
我不提倡使用文档模板，而提倡使用文档写作标准。这是因为模板中会包括太多的东西，你可以需求一些，不需要另外一些。我希望你使用统一的写作方法，这样我就可以明白无误的告诉别人我就是要告诉你这些东西，而不是那些东西，你要是想找到那些东西的答案，我在回答那些问题。
而大家往往有一个误解，就是认为人数越多就需要更多的文档。其实这实在实逻辑上的错误，应该实人们需求得到解答的问题决定文档的多少。我提倡FAQ的123原则，当你第一次遇到一个问题的时候，你就需要口头解答。第二次，你就要留意这个问题，把它放入后备问题列表。第三次就需要把它提升为FAQ。同时我认为后备问题列表应该应该公布，但是要注意它的目的在于你去了解别人在考虑什么，而不是别人在如何解答那些问题。
希望我们的做法对大家有帮助。
首先说到信息失真问题。这个问题早就被大家重视，并且做过很多努力解决的尝试。大家可以参考电梯问题历史。学术上的解决途径是使用形式化语言，但是实用性不强，也无法解决客户和开发者之间的交流问题。
另外一种就是多种文档、多侧面、多方法共同说明，这个是我们常用的方法。但是很容易被文档所误导。特别是不能保持文档同步的时候，情况就更糟糕。而使用机器手段可以保持同步，但是机器生产的文档，有迫于格式的束缚，无法表达书写者的思维意图。
其实如果我们看看电子领域怎么去解决失真问题的，对我们会有启发。你要做一个放大器，你首先可以使用模拟和数码两者选择。数码的放大可以做到完全不失真，但是数模模数转化的时候会失真。而往往我们不需要那么复杂，直接对模拟信号做放大就可以满足我们的要求。而这里有两个方法，一个是步骤很多，放大一次就做一个失真的修正。或者你干脆就选择最少的步骤，一次放大。这个时候你选择失真最小的配件，使用最简单的设计，你会得到最保真的品质。所以你会看到从NE5535导LT1028到今天的更强的运放。而后来大家发现使用火牛和电子管的效果虽然指标不好，但是听感好的多，于是有去追求灯。
软件中的信息其实一样，我们既然已经选择不使用形式化的方法，我们就应该明白不能保证其完全不失真。我们为了降低失真的危害，我们首先应该减少信息流转的步骤，追求信息尽快到达。而同时我们还可以使用辅助手段，比如文档，降低部分失真。但是辅助手段过多一样会带来失真。而同时我们也不要忘记形式化的优点，我们可以采取文档写作使用部分形式化的自然语言。比如我们可以采取实词原则，选择饰词明确原则，选择誓词责任人原则等等。例如说界面迅速作出反映，这显然不能明确说明究竟怎么叫迅速。而界面马上作出反映会好一点，但是马上还是不能明确修饰速度。而你直接说要在一秒内作出反映，就明白无误的告诉对付，速度的要求就是一秒。同样道理我们可以最反映作出逐步的明确含义的解释。
我不提倡使用文档模板，而提倡使用文档写作标准。这是因为模板中会包括太多的东西，你可以需求一些，不需要另外一些。我希望你使用统一的写作方法，这样我就可以明白无误的告诉别人我就是要告诉你这些东西，而不是那些东西，你要是想找到那些东西的答案，我在回答那些问题。
而大家往往有一个误解，就是认为人数越多就需要更多的文档。其实这实在实逻辑上的错误，应该实人们需求得到解答的问题决定文档的多少。我提倡FAQ的123原则，当你第一次遇到一个问题的时候，你就需要口头解答。第二次，你就要留意这个问题，把它放入后备问题列表。第三次就需要把它提升为FAQ。同时我认为后备问题列表应该应该公布，但是要注意它的目的在于你去了解别人在考虑什么，而不是别人在如何解答那些问题。
希望我们的做法对大家有帮助。
#11
呵呵，cjj800(风风火火)，多谢关注。
要不是你，我还不知道我的帖子为什么会沉底呢！
确实是说的糙了些……
正如你说的，我的烦恼就是在不同情况下，该使用那些信息（文档及其它开发工件）进行交流。
RUP的“制品（载体）全是uml”确实没有什么不妥，我的意思是除了uml，还有很多很多精彩的文档格式。
比如页面迁移图、关键字列表、算法的伪码表述、流程图、数据流图、PAD、PCL、MCL……
还有管理上的甘特图、程序变更列表、BUG列表、品质分析图、review记录……
uml是不能包揽软件开发中的各个方面的。特别是进行结构化软件开发的时候。
我说“有一条显著的信息流的线索”，是想弄清楚一些更为基础的东西。
你说工作流，RUP就是这么来描述的。可是我觉得这样不够清楚。:P
角色、制品、交互是一些表面上的东西，驱动它们的是信息传递的需要。
所以我想扒掉它们的皮，看看信息传递的实质。:)
这样在出现问题的时候才能知道是哪条动脉被截断了。
我强调“一条”、“唯一”，是因为我一直坚持标准只能有一个。
比如说确定了一个机能模型，那么其他所有的资料，比如演示文稿、页面迁移图、业务构架说明……都必须服从于这个机能设计。这个机能模型必须使用持久性的文档保存，其他的资料都应该在需要时按模型构建，使用完立即扔掉。
要不是你，我还不知道我的帖子为什么会沉底呢！
确实是说的糙了些……
正如你说的，我的烦恼就是在不同情况下，该使用那些信息（文档及其它开发工件）进行交流。
RUP的“制品（载体）全是uml”确实没有什么不妥，我的意思是除了uml，还有很多很多精彩的文档格式。
比如页面迁移图、关键字列表、算法的伪码表述、流程图、数据流图、PAD、PCL、MCL……
还有管理上的甘特图、程序变更列表、BUG列表、品质分析图、review记录……
uml是不能包揽软件开发中的各个方面的。特别是进行结构化软件开发的时候。
我说“有一条显著的信息流的线索”，是想弄清楚一些更为基础的东西。
你说工作流，RUP就是这么来描述的。可是我觉得这样不够清楚。:P
角色、制品、交互是一些表面上的东西，驱动它们的是信息传递的需要。
所以我想扒掉它们的皮，看看信息传递的实质。:)
这样在出现问题的时候才能知道是哪条动脉被截断了。
我强调“一条”、“唯一”，是因为我一直坚持标准只能有一个。
比如说确定了一个机能模型，那么其他所有的资料，比如演示文稿、页面迁移图、业务构架说明……都必须服从于这个机能设计。这个机能模型必须使用持久性的文档保存，其他的资料都应该在需要时按模型构建，使用完立即扔掉。
#12
谢谢ozzzzzz(希望敏捷)版主指点！！
我也觉得应该尽量减少信息流转的环节，详细设计和编码由同一个人来做最好！！
虽然常说国内的开发流程不规范，但是其中常常有出人意料的闪光点:P
还有就是适当的运用case工具可以减少对持久性文档的需求。
比如说，用Source Insight可以方便的从代码生成函数的调用树，那么就不用去维护一个函数的调用层次图。
依靠代码这个唯一的标准，对辅助文档采取使用时生成、使用后抛弃的原则，可以避免繁重的文档同步工作，也保持了文档的纯洁性。
我也觉得应该尽量减少信息流转的环节，详细设计和编码由同一个人来做最好！！
虽然常说国内的开发流程不规范，但是其中常常有出人意料的闪光点:P
还有就是适当的运用case工具可以减少对持久性文档的需求。
比如说，用Source Insight可以方便的从代码生成函数的调用树，那么就不用去维护一个函数的调用层次图。
依靠代码这个唯一的标准，对辅助文档采取使用时生成、使用后抛弃的原则，可以避免繁重的文档同步工作，也保持了文档的纯洁性。
#13
需求分析的20条法则
邢学慧
---对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。
---经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为*部门提供关于商品营运的报告。”
---分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”
---经理觉得奇怪：“我不是刚告诉你我的需求了吗？”
---分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”
---经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”
---分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”
---经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。”
---风险躲在需求的迷雾之后
---以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。
---拨开需求分析的迷雾
---像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容：
---·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。
---·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。
---·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。
---·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。
---·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。
---前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。其他任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。
---下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。
---经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。
---在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。
---优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。
---由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。
---客户的需求观
---客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。
---1、 分析人员要使用符合客户语言习惯的表达
---需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。
---2、分析人员要了解客户的业务及目标
---只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。s
---3、 分析人员必须编写软件需求报告
---分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。
---4、 要求得到需求工作结果的解释说明
---分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。
---5、 开发人员要尊重客户的意见
---如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。
---6、 开发人员要对需求及产品实施提出建议和解决方案
---通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。
---7、 描述产品使用特性
---客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。
---8、 允许重用已有的软件组件
---需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。
---9、 要求对变更的代价提供真实可靠的评估
---有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。
---10、 获得满足客户功能和质量要求的系统
---每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。
邢学慧
---对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。
---经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为*部门提供关于商品营运的报告。”
---分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”
---经理觉得奇怪：“我不是刚告诉你我的需求了吗？”
---分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”
---经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”
---分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”
---经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。”
---风险躲在需求的迷雾之后
---以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。
---拨开需求分析的迷雾
---像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容：
---·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。
---·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。
---·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。
---·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。
---·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。
---前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。其他任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。
---下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。
---经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。
---在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。
---优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。
---由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。
---客户的需求观
---客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。
---1、 分析人员要使用符合客户语言习惯的表达
---需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。
---2、分析人员要了解客户的业务及目标
---只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。s
---3、 分析人员必须编写软件需求报告
---分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。
---4、 要求得到需求工作结果的解释说明
---分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。
---5、 开发人员要尊重客户的意见
---如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。
---6、 开发人员要对需求及产品实施提出建议和解决方案
---通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。
---7、 描述产品使用特性
---客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。
---8、 允许重用已有的软件组件
---需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。
---9、 要求对变更的代价提供真实可靠的评估
---有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。
---10、 获得满足客户功能和质量要求的系统
---每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。
#14
---11、 给分析人员讲解您的业务
---分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。
---12、 抽出时间清楚地说明并完善需求
---客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。
---13、 准确而详细地说明需求
---编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。
---在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。
---14、 及时作出决定
---分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。
---15、 尊重开发人员的需求可行性及成本评估
---所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。
---16、 划分需求的优先级
---绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。
---在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。
---17、 评审需求文档和原型
---客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。
---更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。
---18、 需求变更要立即联系
---不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。
---19、 遵照开发小组处理需求变更的过程
---为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。
---20、 尊重开发人员采用的需求分析过程
---软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。
---“需求确认”意味着什么
---在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”
---这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”
---同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”
---这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。
---对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。
---需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。
---作者联系： judy-xing@btamail.net.cn
---分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。
---12、 抽出时间清楚地说明并完善需求
---客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。
---13、 准确而详细地说明需求
---编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。
---在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。
---14、 及时作出决定
---分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。
---15、 尊重开发人员的需求可行性及成本评估
---所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。
---16、 划分需求的优先级
---绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。
---在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。
---17、 评审需求文档和原型
---客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。
---更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。
---18、 需求变更要立即联系
---不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。
---19、 遵照开发小组处理需求变更的过程
---为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。
---20、 尊重开发人员采用的需求分析过程
---软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。
---“需求确认”意味着什么
---在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”
---这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”
---同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”
---这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。
---对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。
---需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。
---作者联系： judy-xing@btamail.net.cn
#15
着，真是千呼万唤始出来，犹抱琵琶半遮面。
如楼主所见“适当的运用case工具可以减少对持久性文档的需求”，如果消除对众多文档的依赖，应该有这么一个工具可以生成任何想要得文档，这个工具生成任何想要得文档所依据的就是楼主所述“一条”、“唯一”标准产生的信息。这个标准应该凌驾在诸多标准之上，又能被诸多的标准所解释，这个信息也应该是很“本质”很“元”的。
佩服楼主的想法，这样工具出现的时候也是我们退休的时候。楼主能否讲讲对此标准现已形成的概念。
如楼主所见“适当的运用case工具可以减少对持久性文档的需求”，如果消除对众多文档的依赖，应该有这么一个工具可以生成任何想要得文档，这个工具生成任何想要得文档所依据的就是楼主所述“一条”、“唯一”标准产生的信息。这个标准应该凌驾在诸多标准之上，又能被诸多的标准所解释，这个信息也应该是很“本质”很“元”的。
佩服楼主的想法，这样工具出现的时候也是我们退休的时候。楼主能否讲讲对此标准现已形成的概念。
#16
我的烦恼就是在不同情况下，该使用那些信息（文档及其它开发工件）进行交流。
如何保证信息传递的通畅、信息标准的唯一？
我想楼主是希望能使软件开发过程中产生的各种信息,如需求分析,总体设计,详细设计,或是BUG跟踪,不断变化的需求传达等这一些信息能够畅通,且要能做到信息的传达渠道的一致性,不要今天A模块(AB模块是关联模块,由接口驱动)给出一个接口定义,而明天B模块的设计人员又给出另外一个接口定义,两者不但不同或许还互相矛盾,这就是信息的不一致,导至AB模块的给出结果不一致的原因可能有很多,有一种可能是也许两者看到的需求是前后不同的两个版本,导致这一种问题特别多.这就是信息传递的不畅通.不唯一.
标准:上面指系统分析员作出的需求分析,所有详细设计都应以他的需求分析为标准,这些东西开发设计人员都应该是知道的,造成这种情况不是没有"持久性的文档保存",而是标准所产生的标准变更反应的行为的刷新速度跟不上,造成需求分析人员给出不同需求时相关人员的反应没有同步.
楼主应该是想探索一种能够避免这一些不利情况的工作模式,就是楼主所说的本质的东西,这里面我认为涉及到的东西有复杂的工作流的问题,也是属于一种管理上的东西.这里涉及到的东西相当复杂,简单的说如某人的工作习惯不好,跟进速度不够快,或者某人跟进速度太快,或者某人因为事多,把这事给忘了.不同的阶段,不同的人员都是造成信息传递差异以及对信息处理结果的差异,这种情况是立体的.我想目前世界上应该没有哪一个软件,或是哪一套制度能完全杜绝这一些情况吧.只是很多情况下都是靠开发者管理者的及时的督促跟进才能减少这一些情况的发生,并不断的付出代价来纠正.
不知各位的公司是否是这样,反正我目前的公司就有这一种情况.当然我们也想了很多办法,如使用CVS来统一管理文档,所有的文档以CVS的为准,比如BUG的跟踪系统,比如项目任务的跟踪系统等等,都能在一些方面起到一定的作用.
以上是我个人的一些想法,错误很多,希望能得到各位的指正,本人初涉此道,还处于感知阶段,尚未达到理解贯通,所以特别希望能得到大家的指正.
如何保证信息传递的通畅、信息标准的唯一？
我想楼主是希望能使软件开发过程中产生的各种信息,如需求分析,总体设计,详细设计,或是BUG跟踪,不断变化的需求传达等这一些信息能够畅通,且要能做到信息的传达渠道的一致性,不要今天A模块(AB模块是关联模块,由接口驱动)给出一个接口定义,而明天B模块的设计人员又给出另外一个接口定义,两者不但不同或许还互相矛盾,这就是信息的不一致,导至AB模块的给出结果不一致的原因可能有很多,有一种可能是也许两者看到的需求是前后不同的两个版本,导致这一种问题特别多.这就是信息传递的不畅通.不唯一.
标准:上面指系统分析员作出的需求分析,所有详细设计都应以他的需求分析为标准,这些东西开发设计人员都应该是知道的,造成这种情况不是没有"持久性的文档保存",而是标准所产生的标准变更反应的行为的刷新速度跟不上,造成需求分析人员给出不同需求时相关人员的反应没有同步.
楼主应该是想探索一种能够避免这一些不利情况的工作模式,就是楼主所说的本质的东西,这里面我认为涉及到的东西有复杂的工作流的问题,也是属于一种管理上的东西.这里涉及到的东西相当复杂,简单的说如某人的工作习惯不好,跟进速度不够快,或者某人跟进速度太快,或者某人因为事多,把这事给忘了.不同的阶段,不同的人员都是造成信息传递差异以及对信息处理结果的差异,这种情况是立体的.我想目前世界上应该没有哪一个软件,或是哪一套制度能完全杜绝这一些情况吧.只是很多情况下都是靠开发者管理者的及时的督促跟进才能减少这一些情况的发生,并不断的付出代价来纠正.
不知各位的公司是否是这样,反正我目前的公司就有这一种情况.当然我们也想了很多办法,如使用CVS来统一管理文档,所有的文档以CVS的为准,比如BUG的跟踪系统,比如项目任务的跟踪系统等等,都能在一些方面起到一定的作用.
以上是我个人的一些想法,错误很多,希望能得到各位的指正,本人初涉此道,还处于感知阶段,尚未达到理解贯通,所以特别希望能得到大家的指正.
#17
软件产品的特殊性造成了软件开发主要是智力型的抽象思维活动，这样不可避免的会形成信息的丢失和歧义，我觉得从根本上说没有办法解决，只能通过向软件过程这样定义好活动的文档化产品和提高项目成员的沟通技巧的方式去减少误差。人月神话中的形式化定义这章提出的形式化表示和描述性文字结合的方式结合应该是一个好办法。
楼主所说“我也觉得应该尽量减少信息流转的环节，详细设计和编码由同一个人来做最好！！”这样的方法在小项目中还可行，但是也是不能治本的方法，软件工程化就是向明确分工的方向努力。而“依靠代码这个唯一的标准”本人也不赞同，代码的表示的多样性更能让人迷惑，一个算法十个人写出来至少九个人不一样，代码并不能作为统一的标准。
楼主所说“我也觉得应该尽量减少信息流转的环节，详细设计和编码由同一个人来做最好！！”这样的方法在小项目中还可行，但是也是不能治本的方法，软件工程化就是向明确分工的方向努力。而“依靠代码这个唯一的标准”本人也不赞同，代码的表示的多样性更能让人迷惑，一个算法十个人写出来至少九个人不一样，代码并不能作为统一的标准。
#18
cjj800(风风火火)：
我对这个标准也没有一个完整的想法呢T_T，要不然就不会提问了。
有一个明显的标准是代码。
代码是软件开发中信息流转的最终形态之一（还有用户手册、维护文档什么的），而且它也是一个持久性文档。同时，它是软件开发的一个明确的目的，开发中的大部分成员都时刻使用着它、维护着它。有了这么多的条件，它自然就成为了一种标准。
哈哈，老外喜欢说代码就是设计，我认为其实也就是强调信息流转的连贯性：从需求分析到编写代码都是在搞设计，也就是一直在加工、传递原始信息。
附带说一点，就是在编写完整的代码之前，应该使用条件语句加上注释编写伪码。这样能整理好自己的思路，也留下了很好的文档。有些case工具可以把这些伪码转化成流程图，这样就更容易阅读了。我用过日立的topital，它是一种专注于函数级的case工具，能方便的生成PAD图、函数接口文档，其功能和创意让人非常佩服。可惜国内用过的人好像不多……
但是代码作为标准是有局限性的——它只能给程序员使用！T_T
软件的用户、高高在上的项目主管、千娇百媚舌灿莲花的市场部人员……他们要么看不到代码，要么没时间看代码，要么看不懂代码。
而且代码不是一开始就有的。至少它出现在机能设计之后。
机能设计可以作为编码、测试、编写用户手册的标准。
但是机能设计是一个文档集合，它没有一个确切的定义。
要如何为机能设计选择合适的文档呢？
通常文档之间会有冗余的地方，但是又不能完全抛弃其中的任何一方。
比如说页面说明里会有页面跳转的信息，那么还需不需要一份页面迁移图呢？
这个问题很难回答。
如果没有页面迁移图，也许review会议上的专家们会愤怒地指责：“你有没有听说过一种叫做页面迁移图的东西！？”当然你可以在review会议前赶制一份页面迁移图。但是很明显，从众多的页面文档里整理出一份页面迁移图，将是一份艰辛的费时的工作，以至于不能对它的正确性太过放心。
如果你完全不把这些从来不深入思考，只会从旁边指指点点的专家放在眼里，你也需要为自己考虑一下。如果需要加入新的页面，没有页面迁移图，你有没有勇气奋斗在零零散散的页面文档之间？进行测试，没有页面迁移图，你有没有勇气面对测试人员无休止的询问？
如果同时保存两种信息，那么应该把那种作为标准呢？在多次修改之后，如果出现了信息不一致，早已忙晕了头的你有没有勇气在程序员、测试人员的争执下果断地拍板呢？
如果保留页面迁移图，删除页面文档中关于页面跳转的信息，那么你随时可能被QA主管叫过去骂的狗血喷头。而且有些微妙的东西不能在页面迁移图上明显看出来，你的程序员可能会被测试人员提交的bug数吓死……
呵呵，有点像写小说了……
其实想想，面对大量的数据，商业用户可以使用数据库来组织数据，通过视图随心所欲地选择、组合他们想要的信息。但是我们这些软件的开发者，工具的缔造者，居然只有一个可以比较两个版本异同的版本控制工具！？是不是有些可笑和可悲啊T_T
我对这个标准也没有一个完整的想法呢T_T，要不然就不会提问了。
有一个明显的标准是代码。
代码是软件开发中信息流转的最终形态之一（还有用户手册、维护文档什么的），而且它也是一个持久性文档。同时，它是软件开发的一个明确的目的，开发中的大部分成员都时刻使用着它、维护着它。有了这么多的条件，它自然就成为了一种标准。
哈哈，老外喜欢说代码就是设计，我认为其实也就是强调信息流转的连贯性：从需求分析到编写代码都是在搞设计，也就是一直在加工、传递原始信息。
附带说一点，就是在编写完整的代码之前，应该使用条件语句加上注释编写伪码。这样能整理好自己的思路，也留下了很好的文档。有些case工具可以把这些伪码转化成流程图，这样就更容易阅读了。我用过日立的topital，它是一种专注于函数级的case工具，能方便的生成PAD图、函数接口文档，其功能和创意让人非常佩服。可惜国内用过的人好像不多……
但是代码作为标准是有局限性的——它只能给程序员使用！T_T
软件的用户、高高在上的项目主管、千娇百媚舌灿莲花的市场部人员……他们要么看不到代码，要么没时间看代码，要么看不懂代码。
而且代码不是一开始就有的。至少它出现在机能设计之后。
机能设计可以作为编码、测试、编写用户手册的标准。
但是机能设计是一个文档集合，它没有一个确切的定义。
要如何为机能设计选择合适的文档呢？
通常文档之间会有冗余的地方，但是又不能完全抛弃其中的任何一方。
比如说页面说明里会有页面跳转的信息，那么还需不需要一份页面迁移图呢？
这个问题很难回答。
如果没有页面迁移图，也许review会议上的专家们会愤怒地指责：“你有没有听说过一种叫做页面迁移图的东西！？”当然你可以在review会议前赶制一份页面迁移图。但是很明显，从众多的页面文档里整理出一份页面迁移图，将是一份艰辛的费时的工作，以至于不能对它的正确性太过放心。
如果你完全不把这些从来不深入思考，只会从旁边指指点点的专家放在眼里，你也需要为自己考虑一下。如果需要加入新的页面，没有页面迁移图，你有没有勇气奋斗在零零散散的页面文档之间？进行测试，没有页面迁移图，你有没有勇气面对测试人员无休止的询问？
如果同时保存两种信息，那么应该把那种作为标准呢？在多次修改之后，如果出现了信息不一致，早已忙晕了头的你有没有勇气在程序员、测试人员的争执下果断地拍板呢？
如果保留页面迁移图，删除页面文档中关于页面跳转的信息，那么你随时可能被QA主管叫过去骂的狗血喷头。而且有些微妙的东西不能在页面迁移图上明显看出来，你的程序员可能会被测试人员提交的bug数吓死……
呵呵，有点像写小说了……
其实想想，面对大量的数据，商业用户可以使用数据库来组织数据，通过视图随心所欲地选择、组合他们想要的信息。但是我们这些软件的开发者，工具的缔造者，居然只有一个可以比较两个版本异同的版本控制工具！？是不是有些可笑和可悲啊T_T
#19
我们不应该也不能以文档为中心，而应该以文档的使用为中心。
首先我们来分析 zcwhgj(open-minded) 提到的那种情况－－AB两者不同的接口问题。
首先我想应该在概要设计的时候就定义好成员间的接口，这个接口是公开的透明的。修改这个接口是要按照修改需求那样通过一定的手续的。其实概要设计最重要的就是解决接口问题，然后就是解决任务如何分配的问题。其实概要设计如果在一个组织中，特别是在一个有一点规模的组织中，既是一种技术工作，也是一种管理工作。而且在发布这个概要设计的时候必须有设计者的答疑，这个义务至少要一直持续到项目接受。并且概要设计者要对接口做维护，任何修改建议都应该提交给它，并且在他的组织下讨论修改结果，并由他统一发布。而详细设计我还是建议大家不要做了，当然这要建立在你概要设计的粒度不能太粗的基础上。而现今的实际工作中，我想大家都看到过糟糕概要设计景象：
－》组织大家开一个会，会上决定程序要分为数据库、显示、控制、维护等等几个模块，谁谁负责一个模块。然后就下发一个概要设计文档，遵守GB或者其他格式模板的文档（就像做小学生填空题的作业的概要设计文档）。
这难道就是概要设计吗？
文档的同步问题是一个大问题，其实我们考虑这个问题可以有不同的方法。首先我们可以减少文档的量，也就是减少为达到同步而要做的工作。其次，我们要做到文档中要尽量增加内聚，减少耦合。其次抛弃过时的文档，只使用最新版本的文档。
但是无论怎样，你都应该加强你的配置管理，这是一个效果明显而持久的手段。
软件工程化就是向分工明确化努力，但是不是说分工了就是工程化了。分工必须要建立在确实的解决各个工种间的合作问题，是他们明确找到什么该是谁负责。你只提供给他一堆文档，是不行的。即使是你要给文档，也要给岗位职责说明、岗位操作手册等等有针对性的文档。而不是就给他一个员工手册就完之大吉。但是制定这样的有针对性的文档确实不是好注意，因为你和工厂不一样。他们的生产是稳定的，你可以制定一份文档使用很久，而且给好几个同样职责的岗位使用。而在软件生产中，你显然无法做到这一点。
首先我们来分析 zcwhgj(open-minded) 提到的那种情况－－AB两者不同的接口问题。
首先我想应该在概要设计的时候就定义好成员间的接口，这个接口是公开的透明的。修改这个接口是要按照修改需求那样通过一定的手续的。其实概要设计最重要的就是解决接口问题，然后就是解决任务如何分配的问题。其实概要设计如果在一个组织中，特别是在一个有一点规模的组织中，既是一种技术工作，也是一种管理工作。而且在发布这个概要设计的时候必须有设计者的答疑，这个义务至少要一直持续到项目接受。并且概要设计者要对接口做维护，任何修改建议都应该提交给它，并且在他的组织下讨论修改结果，并由他统一发布。而详细设计我还是建议大家不要做了，当然这要建立在你概要设计的粒度不能太粗的基础上。而现今的实际工作中，我想大家都看到过糟糕概要设计景象：
－》组织大家开一个会，会上决定程序要分为数据库、显示、控制、维护等等几个模块，谁谁负责一个模块。然后就下发一个概要设计文档，遵守GB或者其他格式模板的文档（就像做小学生填空题的作业的概要设计文档）。
这难道就是概要设计吗？
文档的同步问题是一个大问题，其实我们考虑这个问题可以有不同的方法。首先我们可以减少文档的量，也就是减少为达到同步而要做的工作。其次，我们要做到文档中要尽量增加内聚，减少耦合。其次抛弃过时的文档，只使用最新版本的文档。
但是无论怎样，你都应该加强你的配置管理，这是一个效果明显而持久的手段。
软件工程化就是向分工明确化努力，但是不是说分工了就是工程化了。分工必须要建立在确实的解决各个工种间的合作问题，是他们明确找到什么该是谁负责。你只提供给他一堆文档，是不行的。即使是你要给文档，也要给岗位职责说明、岗位操作手册等等有针对性的文档。而不是就给他一个员工手册就完之大吉。但是制定这样的有针对性的文档确实不是好注意，因为你和工厂不一样。他们的生产是稳定的，你可以制定一份文档使用很久，而且给好几个同样职责的岗位使用。而在软件生产中，你显然无法做到这一点。
#20
zcwhgj(open-minded)：
标准不仅是系统分析员作出的需求分析，当然对于概要设计、测试用例、用户手册确实如此。
需求分析的载体（我称为机能设计）本身就是一个中间产品。它参照的标准又是什么？
你说的“刷新速度跟不上”，其实就是信息传递不通畅了:)
用工作流来研究软件开发过程，确实是一个有效的方法。
《统一软件开发过程》这本书就是这么做的。这本书是rational三剑客合写的，相当不错，建议参考。
但是这样研究涉及的东西比较多，比较复杂。
像我这种头脑简单的家伙就喜欢剔除一些杂乱的东西——人性、情趣、环境等等，就抓住抽象数据流转来讨论。
等熟悉了骨架之后，再专心整理其上的皮肉……
标准不仅是系统分析员作出的需求分析，当然对于概要设计、测试用例、用户手册确实如此。
需求分析的载体（我称为机能设计）本身就是一个中间产品。它参照的标准又是什么？
你说的“刷新速度跟不上”，其实就是信息传递不通畅了:)
用工作流来研究软件开发过程，确实是一个有效的方法。
《统一软件开发过程》这本书就是这么做的。这本书是rational三剑客合写的，相当不错，建议参考。
但是这样研究涉及的东西比较多，比较复杂。
像我这种头脑简单的家伙就喜欢剔除一些杂乱的东西——人性、情趣、环境等等，就抓住抽象数据流转来讨论。
等熟悉了骨架之后，再专心整理其上的皮肉……
#21
多谢zhaoxichao(小西)指点。
其实关于信息的丢失和歧义，正如ozzzzzz(希望敏捷)所说，是无法避免的。
我想做的是如何减小信息的丢失和歧义到可以接受的范围。
而软件工程的明确分工问题，我倒是非常感兴趣。
我一直认为高耦合的工作一定要分给一个工作单位做。
这里的工作单位按照规模不同，可以是一个部门、一个小组、一个人。
可以把一部分功能分给一个部门，把一个组件分给一个小组，把一个模块/类分给一个人。
分配任务只需要给工作单位提供接口定义、功能说明、约束条件，其他的就让他们自己发挥吧。
呵呵，这只是我自己的一些感悟，希望前辈们指正！
其实关于信息的丢失和歧义，正如ozzzzzz(希望敏捷)所说，是无法避免的。
我想做的是如何减小信息的丢失和歧义到可以接受的范围。
而软件工程的明确分工问题，我倒是非常感兴趣。
我一直认为高耦合的工作一定要分给一个工作单位做。
这里的工作单位按照规模不同，可以是一个部门、一个小组、一个人。
可以把一部分功能分给一个部门，把一个组件分给一个小组，把一个模块/类分给一个人。
分配任务只需要给工作单位提供接口定义、功能说明、约束条件，其他的就让他们自己发挥吧。
呵呵，这只是我自己的一些感悟，希望前辈们指正！
#22
多谢ozzzzzz(希望敏捷)版主的提醒！
“我们不应该也不能以文档为中心，而应该以文档的使用为中心。”
呵呵，在讨论中不知不觉就从文档的选取运用滑到文档本身了:P
“我们不应该也不能以文档为中心，而应该以文档的使用为中心。”
呵呵，在讨论中不知不觉就从文档的选取运用滑到文档本身了:P
#23
任何形式的信息流转都是可以的，问题是源和目的理解的应该一样就可以了。统一标准当然是一种有效的方法，但是并不是非常有效。因为标准制定者和使用者的差距较大，使用者之间也有差距，这样标准本身的内容就会带来不利于信息流转的因素。个人认为统一一个团队内部被接受的标准就可以了。但是这样做对描述信息的人的要求很高。抓重点，还要说清楚，不太容易。
#24
再次沉底……
T_T
BinaryTreeEx(狂徒)你有些误解了。我的意思就是制订一个自己（团队内部）的标准。所谓统一，指的也是团队内部的统一。
向大家推荐一个网址：http://www.iturls.com/TechHotspot/TH_DocEng.asp，是有关Document Engineering的。努力学习中……
顺便再向大家推荐一篇文章：http://www.iturls.com/Expert/doc/modlref.pdf，《从软件的"胚"谈到模型的参照系》。是关于uml china上的一个讨论的文章，感觉挺有意思的:)
T_T
BinaryTreeEx(狂徒)你有些误解了。我的意思就是制订一个自己（团队内部）的标准。所谓统一，指的也是团队内部的统一。
向大家推荐一个网址：http://www.iturls.com/TechHotspot/TH_DocEng.asp，是有关Document Engineering的。努力学习中……
顺便再向大家推荐一篇文章：http://www.iturls.com/Expert/doc/modlref.pdf，《从软件的"胚"谈到模型的参照系》。是关于uml china上的一个讨论的文章，感觉挺有意思的:)
#25
mark
#1
我想知道你对软件开发过程中信息的定义
#2
终于有人关注了！！！
我说的信息的意思的是：
需求是用户提出来的原始信息。
它经过系统分析员的处理，变成的业务模型的形式，传递给程序设计人员、测试人员、文档人员，为别成为程序设计、测试用例、用户手册的形式。
而程序设计又传递给编码人员，成为代码的形式。
当然，对于不同的开发过程模型，还会有其他不同的中间形式。
在信息的传递过程中，不断地变换形式、加入附加内容。
如何保证信息传递的通畅、信息标准的唯一？这是我关注的问题。
这实际上是软件开发中的communication的问题。
communication不仅仅是口头上的交流，也包含书面的形式。
口头上的交流不是持久的，演示、讨论使用的草图也是一次性的。
必须要有一个唯一的、持久的文本形式的文档来保存当前已知的信息。
虽然代码是最终、最完备的设计，但是由于它过于细致，以至于让人“见木而不见森林”。
如何选择信息的保存格式？如何选择信息的保存时机？
这也是一个变化的问题。
比如一个小项目，分析、设计、开发、测试人员都做在一间小屋子里，那么很多中间文档都可以省略。出于维护的考虑，可能会保留一份模块关系图，一份模块接口说明，以及一份模块功能概要。
但是如果一个大项目，特别是跨项目组、跨公司的项目，就需要把与其他合作团队的接口文档做到非常详细。比如编码由别的公司负责，那么就需要提交十分详细的设计文档。
我也做过一些大大小小的项目，但数量不是很多，种类也不够丰富。
所以希望各位经验丰富的老大们能够提供一些案例，给我一些指导。
再拜！ m(__)m
我说的信息的意思的是：
需求是用户提出来的原始信息。
它经过系统分析员的处理，变成的业务模型的形式，传递给程序设计人员、测试人员、文档人员，为别成为程序设计、测试用例、用户手册的形式。
而程序设计又传递给编码人员，成为代码的形式。
当然，对于不同的开发过程模型，还会有其他不同的中间形式。
在信息的传递过程中，不断地变换形式、加入附加内容。
如何保证信息传递的通畅、信息标准的唯一？这是我关注的问题。
这实际上是软件开发中的communication的问题。
communication不仅仅是口头上的交流，也包含书面的形式。
口头上的交流不是持久的，演示、讨论使用的草图也是一次性的。
必须要有一个唯一的、持久的文本形式的文档来保存当前已知的信息。
虽然代码是最终、最完备的设计，但是由于它过于细致，以至于让人“见木而不见森林”。
如何选择信息的保存格式？如何选择信息的保存时机？
这也是一个变化的问题。
比如一个小项目，分析、设计、开发、测试人员都做在一间小屋子里，那么很多中间文档都可以省略。出于维护的考虑，可能会保留一份模块关系图，一份模块接口说明，以及一份模块功能概要。
但是如果一个大项目，特别是跨项目组、跨公司的项目，就需要把与其他合作团队的接口文档做到非常详细。比如编码由别的公司负责，那么就需要提交十分详细的设计文档。
我也做过一些大大小小的项目，但数量不是很多，种类也不够丰富。
所以希望各位经验丰富的老大们能够提供一些案例，给我一些指导。
再拜！ m(__)m
#3
或者应该叫做：“effective documentation in software developing”？
:)
:)
#4
软件工程的每个阶段,都要有相应的设计文件,即文件产品.
这些文件产品就是项目信息流的载体.
如:项目需求分析,总体设计,概要设计,详细设计等.
这些设计文件必须要标准化.
小组内部要有标准,软件企业自己要有标准,
进行联合开发或外包,设计文件就要符合行业标准.
大家按一种标准来协作,才能保证信息流没有差异的传递.
文档模版就是一种标准.
UML也是一种标准.
这些文件产品就是项目信息流的载体.
如:项目需求分析,总体设计,概要设计,详细设计等.
这些设计文件必须要标准化.
小组内部要有标准,软件企业自己要有标准,
进行联合开发或外包,设计文件就要符合行业标准.
大家按一种标准来协作,才能保证信息流没有差异的传递.
文档模版就是一种标准.
UML也是一种标准.
#5
谢谢版主指点!!
我现在的疑问正好是如何制定自己的标准。
:)
RUP提倡重量型文档，AP提倡轻量型文档。而在实践中，需要选择合适的文档。
面对各式各样的文档模板，如何做出选择？
我们首先必须明白信息如何流转，以及哪些信息是有效的、哪些信息是需要持久保存的。
开发过程中软件本身的信息流就已经很麻烦，再加上管理使用的信息流……
头晕了头晕了……
我现在的疑问正好是如何制定自己的标准。
:)
RUP提倡重量型文档，AP提倡轻量型文档。而在实践中，需要选择合适的文档。
面对各式各样的文档模板，如何做出选择？
我们首先必须明白信息如何流转，以及哪些信息是有效的、哪些信息是需要持久保存的。
开发过程中软件本身的信息流就已经很麻烦，再加上管理使用的信息流……
头晕了头晕了……
#6
抱歉，有些表述不清……
我说的“制定自己的标准”，
是说在项目中传输信息的标准，
也就是在什么时机、运用什么样的文档、使用什么样的方式来进行交流。
我说的“制定自己的标准”，
是说在项目中传输信息的标准，
也就是在什么时机、运用什么样的文档、使用什么样的方式来进行交流。
#7
首先请楼主莫怪,我问楼主信息的定义是怕引起交流二义性。
其实楼主对软件开发过程中的文档的重要性有相当的见解。“effective documentation”的定义十分精确，楼主烦恼的是在不同情况下，该使用那些信息（文档及其它开发工件）进行交流？楼主说的制定自己的标准，是不是在项目开发过程中根据项目的外在环境和内在环境的制定出一套信息交流的方式，使之达到“多一分则太赤,少一分则太白”的境界。
其实楼主对软件开发过程中的文档的重要性有相当的见解。“effective documentation”的定义十分精确，楼主烦恼的是在不同情况下，该使用那些信息（文档及其它开发工件）进行交流？楼主说的制定自己的标准，是不是在项目开发过程中根据项目的外在环境和内在环境的制定出一套信息交流的方式，使之达到“多一分则太赤,少一分则太白”的境界。
#8
开始做设计，以前做程序的，学习来了。
#9
《RUP》我有幸也看过，但是说RUP提倡重量型文档,我倒不这样认为。举个例子，RUP涉及的文档好比是对一个类的所有状态的描述，而我们对这个类的一次方法调用，不一定要遍历所有的状态。我们可以对RUP进行剪切，使之适应我们的项目开发。
RUP的“制品（载体）全是uml”实际也没有什么不妥，就象tj_dns(愉快的登山者 MVP)所说 “UML也是一种标准”，使用UML产生的各种图，就是我们要交流的信息，只有按照大家认同标准产生的信息，才能被大家理解和接受，就象许多跨国软件项目要求用英语写文档一样。
软件开发中的信息流转，并不是指“有一条显著的信息流的线索”，我觉得理解为工作流更妥当一些。可以看看工作流的三个要素：角色、相关数据、转移条件。软件开发过程中，对开发人员进行角色划分，这是大家所认同的。这样可以使工作分工明确，易于管理，使开发过程中产生的信息更有针对性；我们所书写的文档及其它工件可以看作软件开发过程中流转的信息；转移条件可以，看作是一次里程碑的结束。这样的理解可以使软件开发过程更具立体感、阶段性和层次性。
一己之见，还望指正。
RUP的“制品（载体）全是uml”实际也没有什么不妥，就象tj_dns(愉快的登山者 MVP)所说 “UML也是一种标准”，使用UML产生的各种图，就是我们要交流的信息，只有按照大家认同标准产生的信息，才能被大家理解和接受，就象许多跨国软件项目要求用英语写文档一样。
软件开发中的信息流转，并不是指“有一条显著的信息流的线索”，我觉得理解为工作流更妥当一些。可以看看工作流的三个要素：角色、相关数据、转移条件。软件开发过程中，对开发人员进行角色划分，这是大家所认同的。这样可以使工作分工明确，易于管理，使开发过程中产生的信息更有针对性；我们所书写的文档及其它工件可以看作软件开发过程中流转的信息；转移条件可以，看作是一次里程碑的结束。这样的理解可以使软件开发过程更具立体感、阶段性和层次性。
一己之见，还望指正。
#10
看了几天，也想了几天，但是还是没有想太明白。不过还是进来，给大家分享我的结果。
首先说到信息失真问题。这个问题早就被大家重视，并且做过很多努力解决的尝试。大家可以参考电梯问题历史。学术上的解决途径是使用形式化语言，但是实用性不强，也无法解决客户和开发者之间的交流问题。
另外一种就是多种文档、多侧面、多方法共同说明，这个是我们常用的方法。但是很容易被文档所误导。特别是不能保持文档同步的时候，情况就更糟糕。而使用机器手段可以保持同步，但是机器生产的文档，有迫于格式的束缚，无法表达书写者的思维意图。
其实如果我们看看电子领域怎么去解决失真问题的，对我们会有启发。你要做一个放大器，你首先可以使用模拟和数码两者选择。数码的放大可以做到完全不失真，但是数模模数转化的时候会失真。而往往我们不需要那么复杂，直接对模拟信号做放大就可以满足我们的要求。而这里有两个方法，一个是步骤很多，放大一次就做一个失真的修正。或者你干脆就选择最少的步骤，一次放大。这个时候你选择失真最小的配件，使用最简单的设计，你会得到最保真的品质。所以你会看到从NE5535导LT1028到今天的更强的运放。而后来大家发现使用火牛和电子管的效果虽然指标不好，但是听感好的多，于是有去追求灯。
软件中的信息其实一样，我们既然已经选择不使用形式化的方法，我们就应该明白不能保证其完全不失真。我们为了降低失真的危害，我们首先应该减少信息流转的步骤，追求信息尽快到达。而同时我们还可以使用辅助手段，比如文档，降低部分失真。但是辅助手段过多一样会带来失真。而同时我们也不要忘记形式化的优点，我们可以采取文档写作使用部分形式化的自然语言。比如我们可以采取实词原则，选择饰词明确原则，选择誓词责任人原则等等。例如说界面迅速作出反映，这显然不能明确说明究竟怎么叫迅速。而界面马上作出反映会好一点，但是马上还是不能明确修饰速度。而你直接说要在一秒内作出反映，就明白无误的告诉对付，速度的要求就是一秒。同样道理我们可以最反映作出逐步的明确含义的解释。
我不提倡使用文档模板，而提倡使用文档写作标准。这是因为模板中会包括太多的东西，你可以需求一些，不需要另外一些。我希望你使用统一的写作方法，这样我就可以明白无误的告诉别人我就是要告诉你这些东西，而不是那些东西，你要是想找到那些东西的答案，我在回答那些问题。
而大家往往有一个误解，就是认为人数越多就需要更多的文档。其实这实在实逻辑上的错误，应该实人们需求得到解答的问题决定文档的多少。我提倡FAQ的123原则，当你第一次遇到一个问题的时候，你就需要口头解答。第二次，你就要留意这个问题，把它放入后备问题列表。第三次就需要把它提升为FAQ。同时我认为后备问题列表应该应该公布，但是要注意它的目的在于你去了解别人在考虑什么，而不是别人在如何解答那些问题。
希望我们的做法对大家有帮助。
首先说到信息失真问题。这个问题早就被大家重视，并且做过很多努力解决的尝试。大家可以参考电梯问题历史。学术上的解决途径是使用形式化语言，但是实用性不强，也无法解决客户和开发者之间的交流问题。
另外一种就是多种文档、多侧面、多方法共同说明，这个是我们常用的方法。但是很容易被文档所误导。特别是不能保持文档同步的时候，情况就更糟糕。而使用机器手段可以保持同步，但是机器生产的文档，有迫于格式的束缚，无法表达书写者的思维意图。
其实如果我们看看电子领域怎么去解决失真问题的，对我们会有启发。你要做一个放大器，你首先可以使用模拟和数码两者选择。数码的放大可以做到完全不失真，但是数模模数转化的时候会失真。而往往我们不需要那么复杂，直接对模拟信号做放大就可以满足我们的要求。而这里有两个方法，一个是步骤很多，放大一次就做一个失真的修正。或者你干脆就选择最少的步骤，一次放大。这个时候你选择失真最小的配件，使用最简单的设计，你会得到最保真的品质。所以你会看到从NE5535导LT1028到今天的更强的运放。而后来大家发现使用火牛和电子管的效果虽然指标不好，但是听感好的多，于是有去追求灯。
软件中的信息其实一样，我们既然已经选择不使用形式化的方法，我们就应该明白不能保证其完全不失真。我们为了降低失真的危害，我们首先应该减少信息流转的步骤，追求信息尽快到达。而同时我们还可以使用辅助手段，比如文档，降低部分失真。但是辅助手段过多一样会带来失真。而同时我们也不要忘记形式化的优点，我们可以采取文档写作使用部分形式化的自然语言。比如我们可以采取实词原则，选择饰词明确原则，选择誓词责任人原则等等。例如说界面迅速作出反映，这显然不能明确说明究竟怎么叫迅速。而界面马上作出反映会好一点，但是马上还是不能明确修饰速度。而你直接说要在一秒内作出反映，就明白无误的告诉对付，速度的要求就是一秒。同样道理我们可以最反映作出逐步的明确含义的解释。
我不提倡使用文档模板，而提倡使用文档写作标准。这是因为模板中会包括太多的东西，你可以需求一些，不需要另外一些。我希望你使用统一的写作方法，这样我就可以明白无误的告诉别人我就是要告诉你这些东西，而不是那些东西，你要是想找到那些东西的答案，我在回答那些问题。
而大家往往有一个误解，就是认为人数越多就需要更多的文档。其实这实在实逻辑上的错误，应该实人们需求得到解答的问题决定文档的多少。我提倡FAQ的123原则，当你第一次遇到一个问题的时候，你就需要口头解答。第二次，你就要留意这个问题，把它放入后备问题列表。第三次就需要把它提升为FAQ。同时我认为后备问题列表应该应该公布，但是要注意它的目的在于你去了解别人在考虑什么，而不是别人在如何解答那些问题。
希望我们的做法对大家有帮助。
#11
呵呵，cjj800(风风火火)，多谢关注。
要不是你，我还不知道我的帖子为什么会沉底呢！
确实是说的糙了些……
正如你说的，我的烦恼就是在不同情况下，该使用那些信息（文档及其它开发工件）进行交流。
RUP的“制品（载体）全是uml”确实没有什么不妥，我的意思是除了uml，还有很多很多精彩的文档格式。
比如页面迁移图、关键字列表、算法的伪码表述、流程图、数据流图、PAD、PCL、MCL……
还有管理上的甘特图、程序变更列表、BUG列表、品质分析图、review记录……
uml是不能包揽软件开发中的各个方面的。特别是进行结构化软件开发的时候。
我说“有一条显著的信息流的线索”，是想弄清楚一些更为基础的东西。
你说工作流，RUP就是这么来描述的。可是我觉得这样不够清楚。:P
角色、制品、交互是一些表面上的东西，驱动它们的是信息传递的需要。
所以我想扒掉它们的皮，看看信息传递的实质。:)
这样在出现问题的时候才能知道是哪条动脉被截断了。
我强调“一条”、“唯一”，是因为我一直坚持标准只能有一个。
比如说确定了一个机能模型，那么其他所有的资料，比如演示文稿、页面迁移图、业务构架说明……都必须服从于这个机能设计。这个机能模型必须使用持久性的文档保存，其他的资料都应该在需要时按模型构建，使用完立即扔掉。
要不是你，我还不知道我的帖子为什么会沉底呢！
确实是说的糙了些……
正如你说的，我的烦恼就是在不同情况下，该使用那些信息（文档及其它开发工件）进行交流。
RUP的“制品（载体）全是uml”确实没有什么不妥，我的意思是除了uml，还有很多很多精彩的文档格式。
比如页面迁移图、关键字列表、算法的伪码表述、流程图、数据流图、PAD、PCL、MCL……
还有管理上的甘特图、程序变更列表、BUG列表、品质分析图、review记录……
uml是不能包揽软件开发中的各个方面的。特别是进行结构化软件开发的时候。
我说“有一条显著的信息流的线索”，是想弄清楚一些更为基础的东西。
你说工作流，RUP就是这么来描述的。可是我觉得这样不够清楚。:P
角色、制品、交互是一些表面上的东西，驱动它们的是信息传递的需要。
所以我想扒掉它们的皮，看看信息传递的实质。:)
这样在出现问题的时候才能知道是哪条动脉被截断了。
我强调“一条”、“唯一”，是因为我一直坚持标准只能有一个。
比如说确定了一个机能模型，那么其他所有的资料，比如演示文稿、页面迁移图、业务构架说明……都必须服从于这个机能设计。这个机能模型必须使用持久性的文档保存，其他的资料都应该在需要时按模型构建，使用完立即扔掉。
#12
谢谢ozzzzzz(希望敏捷)版主指点！！
我也觉得应该尽量减少信息流转的环节，详细设计和编码由同一个人来做最好！！
虽然常说国内的开发流程不规范，但是其中常常有出人意料的闪光点:P
还有就是适当的运用case工具可以减少对持久性文档的需求。
比如说，用Source Insight可以方便的从代码生成函数的调用树，那么就不用去维护一个函数的调用层次图。
依靠代码这个唯一的标准，对辅助文档采取使用时生成、使用后抛弃的原则，可以避免繁重的文档同步工作，也保持了文档的纯洁性。
我也觉得应该尽量减少信息流转的环节，详细设计和编码由同一个人来做最好！！
虽然常说国内的开发流程不规范，但是其中常常有出人意料的闪光点:P
还有就是适当的运用case工具可以减少对持久性文档的需求。
比如说，用Source Insight可以方便的从代码生成函数的调用树，那么就不用去维护一个函数的调用层次图。
依靠代码这个唯一的标准，对辅助文档采取使用时生成、使用后抛弃的原则，可以避免繁重的文档同步工作，也保持了文档的纯洁性。
#13
需求分析的20条法则
邢学慧
---对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。
---经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为*部门提供关于商品营运的报告。”
---分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”
---经理觉得奇怪：“我不是刚告诉你我的需求了吗？”
---分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”
---经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”
---分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”
---经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。”
---风险躲在需求的迷雾之后
---以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。
---拨开需求分析的迷雾
---像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容：
---·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。
---·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。
---·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。
---·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。
---·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。
---前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。其他任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。
---下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。
---经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。
---在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。
---优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。
---由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。
---客户的需求观
---客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。
---1、 分析人员要使用符合客户语言习惯的表达
---需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。
---2、分析人员要了解客户的业务及目标
---只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。s
---3、 分析人员必须编写软件需求报告
---分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。
---4、 要求得到需求工作结果的解释说明
---分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。
---5、 开发人员要尊重客户的意见
---如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。
---6、 开发人员要对需求及产品实施提出建议和解决方案
---通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。
---7、 描述产品使用特性
---客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。
---8、 允许重用已有的软件组件
---需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。
---9、 要求对变更的代价提供真实可靠的评估
---有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。
---10、 获得满足客户功能和质量要求的系统
---每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。
邢学慧
---对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。
---经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为*部门提供关于商品营运的报告。”
---分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”
---经理觉得奇怪：“我不是刚告诉你我的需求了吗？”
---分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”
---经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”
---分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”
---经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。”
---风险躲在需求的迷雾之后
---以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。
---拨开需求分析的迷雾
---像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容：
---·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。
---·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。
---·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。
---·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。
---·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。
---前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。其他任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。
---下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。
---经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。
---在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。
---优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。
---由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。
---客户的需求观
---客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。
---1、 分析人员要使用符合客户语言习惯的表达
---需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。
---2、分析人员要了解客户的业务及目标
---只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。s
---3、 分析人员必须编写软件需求报告
---分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。
---4、 要求得到需求工作结果的解释说明
---分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。
---5、 开发人员要尊重客户的意见
---如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。
---6、 开发人员要对需求及产品实施提出建议和解决方案
---通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。
---7、 描述产品使用特性
---客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。
---8、 允许重用已有的软件组件
---需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。
---9、 要求对变更的代价提供真实可靠的评估
---有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。
---10、 获得满足客户功能和质量要求的系统
---每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。
#14
---11、 给分析人员讲解您的业务
---分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。
---12、 抽出时间清楚地说明并完善需求
---客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。
---13、 准确而详细地说明需求
---编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。
---在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。
---14、 及时作出决定
---分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。
---15、 尊重开发人员的需求可行性及成本评估
---所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。
---16、 划分需求的优先级
---绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。
---在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。
---17、 评审需求文档和原型
---客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。
---更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。
---18、 需求变更要立即联系
---不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。
---19、 遵照开发小组处理需求变更的过程
---为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。
---20、 尊重开发人员采用的需求分析过程
---软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。
---“需求确认”意味着什么
---在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”
---这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”
---同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”
---这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。
---对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。
---需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。
---作者联系： judy-xing@btamail.net.cn
---分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。
---12、 抽出时间清楚地说明并完善需求
---客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。
---13、 准确而详细地说明需求
---编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。
---在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。
---14、 及时作出决定
---分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。
---15、 尊重开发人员的需求可行性及成本评估
---所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。
---16、 划分需求的优先级
---绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。
---在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。
---17、 评审需求文档和原型
---客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。
---更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。
---18、 需求变更要立即联系
---不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。
---19、 遵照开发小组处理需求变更的过程
---为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。
---20、 尊重开发人员采用的需求分析过程
---软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。
---“需求确认”意味着什么
---在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”
---这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”
---同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”
---这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。
---对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。
---需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。
---作者联系： judy-xing@btamail.net.cn
#15
着，真是千呼万唤始出来，犹抱琵琶半遮面。
如楼主所见“适当的运用case工具可以减少对持久性文档的需求”，如果消除对众多文档的依赖，应该有这么一个工具可以生成任何想要得文档，这个工具生成任何想要得文档所依据的就是楼主所述“一条”、“唯一”标准产生的信息。这个标准应该凌驾在诸多标准之上，又能被诸多的标准所解释，这个信息也应该是很“本质”很“元”的。
佩服楼主的想法，这样工具出现的时候也是我们退休的时候。楼主能否讲讲对此标准现已形成的概念。
如楼主所见“适当的运用case工具可以减少对持久性文档的需求”，如果消除对众多文档的依赖，应该有这么一个工具可以生成任何想要得文档，这个工具生成任何想要得文档所依据的就是楼主所述“一条”、“唯一”标准产生的信息。这个标准应该凌驾在诸多标准之上，又能被诸多的标准所解释，这个信息也应该是很“本质”很“元”的。
佩服楼主的想法，这样工具出现的时候也是我们退休的时候。楼主能否讲讲对此标准现已形成的概念。
#16
我的烦恼就是在不同情况下，该使用那些信息（文档及其它开发工件）进行交流。
如何保证信息传递的通畅、信息标准的唯一？
我想楼主是希望能使软件开发过程中产生的各种信息,如需求分析,总体设计,详细设计,或是BUG跟踪,不断变化的需求传达等这一些信息能够畅通,且要能做到信息的传达渠道的一致性,不要今天A模块(AB模块是关联模块,由接口驱动)给出一个接口定义,而明天B模块的设计人员又给出另外一个接口定义,两者不但不同或许还互相矛盾,这就是信息的不一致,导至AB模块的给出结果不一致的原因可能有很多,有一种可能是也许两者看到的需求是前后不同的两个版本,导致这一种问题特别多.这就是信息传递的不畅通.不唯一.
标准:上面指系统分析员作出的需求分析,所有详细设计都应以他的需求分析为标准,这些东西开发设计人员都应该是知道的,造成这种情况不是没有"持久性的文档保存",而是标准所产生的标准变更反应的行为的刷新速度跟不上,造成需求分析人员给出不同需求时相关人员的反应没有同步.
楼主应该是想探索一种能够避免这一些不利情况的工作模式,就是楼主所说的本质的东西,这里面我认为涉及到的东西有复杂的工作流的问题,也是属于一种管理上的东西.这里涉及到的东西相当复杂,简单的说如某人的工作习惯不好,跟进速度不够快,或者某人跟进速度太快,或者某人因为事多,把这事给忘了.不同的阶段,不同的人员都是造成信息传递差异以及对信息处理结果的差异,这种情况是立体的.我想目前世界上应该没有哪一个软件,或是哪一套制度能完全杜绝这一些情况吧.只是很多情况下都是靠开发者管理者的及时的督促跟进才能减少这一些情况的发生,并不断的付出代价来纠正.
不知各位的公司是否是这样,反正我目前的公司就有这一种情况.当然我们也想了很多办法,如使用CVS来统一管理文档,所有的文档以CVS的为准,比如BUG的跟踪系统,比如项目任务的跟踪系统等等,都能在一些方面起到一定的作用.
以上是我个人的一些想法,错误很多,希望能得到各位的指正,本人初涉此道,还处于感知阶段,尚未达到理解贯通,所以特别希望能得到大家的指正.
如何保证信息传递的通畅、信息标准的唯一？
我想楼主是希望能使软件开发过程中产生的各种信息,如需求分析,总体设计,详细设计,或是BUG跟踪,不断变化的需求传达等这一些信息能够畅通,且要能做到信息的传达渠道的一致性,不要今天A模块(AB模块是关联模块,由接口驱动)给出一个接口定义,而明天B模块的设计人员又给出另外一个接口定义,两者不但不同或许还互相矛盾,这就是信息的不一致,导至AB模块的给出结果不一致的原因可能有很多,有一种可能是也许两者看到的需求是前后不同的两个版本,导致这一种问题特别多.这就是信息传递的不畅通.不唯一.
标准:上面指系统分析员作出的需求分析,所有详细设计都应以他的需求分析为标准,这些东西开发设计人员都应该是知道的,造成这种情况不是没有"持久性的文档保存",而是标准所产生的标准变更反应的行为的刷新速度跟不上,造成需求分析人员给出不同需求时相关人员的反应没有同步.
楼主应该是想探索一种能够避免这一些不利情况的工作模式,就是楼主所说的本质的东西,这里面我认为涉及到的东西有复杂的工作流的问题,也是属于一种管理上的东西.这里涉及到的东西相当复杂,简单的说如某人的工作习惯不好,跟进速度不够快,或者某人跟进速度太快,或者某人因为事多,把这事给忘了.不同的阶段,不同的人员都是造成信息传递差异以及对信息处理结果的差异,这种情况是立体的.我想目前世界上应该没有哪一个软件,或是哪一套制度能完全杜绝这一些情况吧.只是很多情况下都是靠开发者管理者的及时的督促跟进才能减少这一些情况的发生,并不断的付出代价来纠正.
不知各位的公司是否是这样,反正我目前的公司就有这一种情况.当然我们也想了很多办法,如使用CVS来统一管理文档,所有的文档以CVS的为准,比如BUG的跟踪系统,比如项目任务的跟踪系统等等,都能在一些方面起到一定的作用.
以上是我个人的一些想法,错误很多,希望能得到各位的指正,本人初涉此道,还处于感知阶段,尚未达到理解贯通,所以特别希望能得到大家的指正.
#17
软件产品的特殊性造成了软件开发主要是智力型的抽象思维活动，这样不可避免的会形成信息的丢失和歧义，我觉得从根本上说没有办法解决，只能通过向软件过程这样定义好活动的文档化产品和提高项目成员的沟通技巧的方式去减少误差。人月神话中的形式化定义这章提出的形式化表示和描述性文字结合的方式结合应该是一个好办法。
楼主所说“我也觉得应该尽量减少信息流转的环节，详细设计和编码由同一个人来做最好！！”这样的方法在小项目中还可行，但是也是不能治本的方法，软件工程化就是向明确分工的方向努力。而“依靠代码这个唯一的标准”本人也不赞同，代码的表示的多样性更能让人迷惑，一个算法十个人写出来至少九个人不一样，代码并不能作为统一的标准。
楼主所说“我也觉得应该尽量减少信息流转的环节，详细设计和编码由同一个人来做最好！！”这样的方法在小项目中还可行，但是也是不能治本的方法，软件工程化就是向明确分工的方向努力。而“依靠代码这个唯一的标准”本人也不赞同，代码的表示的多样性更能让人迷惑，一个算法十个人写出来至少九个人不一样，代码并不能作为统一的标准。
#18
cjj800(风风火火)：
我对这个标准也没有一个完整的想法呢T_T，要不然就不会提问了。
有一个明显的标准是代码。
代码是软件开发中信息流转的最终形态之一（还有用户手册、维护文档什么的），而且它也是一个持久性文档。同时，它是软件开发的一个明确的目的，开发中的大部分成员都时刻使用着它、维护着它。有了这么多的条件，它自然就成为了一种标准。
哈哈，老外喜欢说代码就是设计，我认为其实也就是强调信息流转的连贯性：从需求分析到编写代码都是在搞设计，也就是一直在加工、传递原始信息。
附带说一点，就是在编写完整的代码之前，应该使用条件语句加上注释编写伪码。这样能整理好自己的思路，也留下了很好的文档。有些case工具可以把这些伪码转化成流程图，这样就更容易阅读了。我用过日立的topital，它是一种专注于函数级的case工具，能方便的生成PAD图、函数接口文档，其功能和创意让人非常佩服。可惜国内用过的人好像不多……
但是代码作为标准是有局限性的——它只能给程序员使用！T_T
软件的用户、高高在上的项目主管、千娇百媚舌灿莲花的市场部人员……他们要么看不到代码，要么没时间看代码，要么看不懂代码。
而且代码不是一开始就有的。至少它出现在机能设计之后。
机能设计可以作为编码、测试、编写用户手册的标准。
但是机能设计是一个文档集合，它没有一个确切的定义。
要如何为机能设计选择合适的文档呢？
通常文档之间会有冗余的地方，但是又不能完全抛弃其中的任何一方。
比如说页面说明里会有页面跳转的信息，那么还需不需要一份页面迁移图呢？
这个问题很难回答。
如果没有页面迁移图，也许review会议上的专家们会愤怒地指责：“你有没有听说过一种叫做页面迁移图的东西！？”当然你可以在review会议前赶制一份页面迁移图。但是很明显，从众多的页面文档里整理出一份页面迁移图，将是一份艰辛的费时的工作，以至于不能对它的正确性太过放心。
如果你完全不把这些从来不深入思考，只会从旁边指指点点的专家放在眼里，你也需要为自己考虑一下。如果需要加入新的页面，没有页面迁移图，你有没有勇气奋斗在零零散散的页面文档之间？进行测试，没有页面迁移图，你有没有勇气面对测试人员无休止的询问？
如果同时保存两种信息，那么应该把那种作为标准呢？在多次修改之后，如果出现了信息不一致，早已忙晕了头的你有没有勇气在程序员、测试人员的争执下果断地拍板呢？
如果保留页面迁移图，删除页面文档中关于页面跳转的信息，那么你随时可能被QA主管叫过去骂的狗血喷头。而且有些微妙的东西不能在页面迁移图上明显看出来，你的程序员可能会被测试人员提交的bug数吓死……
呵呵，有点像写小说了……
其实想想，面对大量的数据，商业用户可以使用数据库来组织数据，通过视图随心所欲地选择、组合他们想要的信息。但是我们这些软件的开发者，工具的缔造者，居然只有一个可以比较两个版本异同的版本控制工具！？是不是有些可笑和可悲啊T_T
我对这个标准也没有一个完整的想法呢T_T，要不然就不会提问了。
有一个明显的标准是代码。
代码是软件开发中信息流转的最终形态之一（还有用户手册、维护文档什么的），而且它也是一个持久性文档。同时，它是软件开发的一个明确的目的，开发中的大部分成员都时刻使用着它、维护着它。有了这么多的条件，它自然就成为了一种标准。
哈哈，老外喜欢说代码就是设计，我认为其实也就是强调信息流转的连贯性：从需求分析到编写代码都是在搞设计，也就是一直在加工、传递原始信息。
附带说一点，就是在编写完整的代码之前，应该使用条件语句加上注释编写伪码。这样能整理好自己的思路，也留下了很好的文档。有些case工具可以把这些伪码转化成流程图，这样就更容易阅读了。我用过日立的topital，它是一种专注于函数级的case工具，能方便的生成PAD图、函数接口文档，其功能和创意让人非常佩服。可惜国内用过的人好像不多……
但是代码作为标准是有局限性的——它只能给程序员使用！T_T
软件的用户、高高在上的项目主管、千娇百媚舌灿莲花的市场部人员……他们要么看不到代码，要么没时间看代码，要么看不懂代码。
而且代码不是一开始就有的。至少它出现在机能设计之后。
机能设计可以作为编码、测试、编写用户手册的标准。
但是机能设计是一个文档集合，它没有一个确切的定义。
要如何为机能设计选择合适的文档呢？
通常文档之间会有冗余的地方，但是又不能完全抛弃其中的任何一方。
比如说页面说明里会有页面跳转的信息，那么还需不需要一份页面迁移图呢？
这个问题很难回答。
如果没有页面迁移图，也许review会议上的专家们会愤怒地指责：“你有没有听说过一种叫做页面迁移图的东西！？”当然你可以在review会议前赶制一份页面迁移图。但是很明显，从众多的页面文档里整理出一份页面迁移图，将是一份艰辛的费时的工作，以至于不能对它的正确性太过放心。
如果你完全不把这些从来不深入思考，只会从旁边指指点点的专家放在眼里，你也需要为自己考虑一下。如果需要加入新的页面，没有页面迁移图，你有没有勇气奋斗在零零散散的页面文档之间？进行测试，没有页面迁移图，你有没有勇气面对测试人员无休止的询问？
如果同时保存两种信息，那么应该把那种作为标准呢？在多次修改之后，如果出现了信息不一致，早已忙晕了头的你有没有勇气在程序员、测试人员的争执下果断地拍板呢？
如果保留页面迁移图，删除页面文档中关于页面跳转的信息，那么你随时可能被QA主管叫过去骂的狗血喷头。而且有些微妙的东西不能在页面迁移图上明显看出来，你的程序员可能会被测试人员提交的bug数吓死……
呵呵，有点像写小说了……
其实想想，面对大量的数据，商业用户可以使用数据库来组织数据，通过视图随心所欲地选择、组合他们想要的信息。但是我们这些软件的开发者，工具的缔造者，居然只有一个可以比较两个版本异同的版本控制工具！？是不是有些可笑和可悲啊T_T
#19
我们不应该也不能以文档为中心，而应该以文档的使用为中心。
首先我们来分析 zcwhgj(open-minded) 提到的那种情况－－AB两者不同的接口问题。
首先我想应该在概要设计的时候就定义好成员间的接口，这个接口是公开的透明的。修改这个接口是要按照修改需求那样通过一定的手续的。其实概要设计最重要的就是解决接口问题，然后就是解决任务如何分配的问题。其实概要设计如果在一个组织中，特别是在一个有一点规模的组织中，既是一种技术工作，也是一种管理工作。而且在发布这个概要设计的时候必须有设计者的答疑，这个义务至少要一直持续到项目接受。并且概要设计者要对接口做维护，任何修改建议都应该提交给它，并且在他的组织下讨论修改结果，并由他统一发布。而详细设计我还是建议大家不要做了，当然这要建立在你概要设计的粒度不能太粗的基础上。而现今的实际工作中，我想大家都看到过糟糕概要设计景象：
－》组织大家开一个会，会上决定程序要分为数据库、显示、控制、维护等等几个模块，谁谁负责一个模块。然后就下发一个概要设计文档，遵守GB或者其他格式模板的文档（就像做小学生填空题的作业的概要设计文档）。
这难道就是概要设计吗？
文档的同步问题是一个大问题，其实我们考虑这个问题可以有不同的方法。首先我们可以减少文档的量，也就是减少为达到同步而要做的工作。其次，我们要做到文档中要尽量增加内聚，减少耦合。其次抛弃过时的文档，只使用最新版本的文档。
但是无论怎样，你都应该加强你的配置管理，这是一个效果明显而持久的手段。
软件工程化就是向分工明确化努力，但是不是说分工了就是工程化了。分工必须要建立在确实的解决各个工种间的合作问题，是他们明确找到什么该是谁负责。你只提供给他一堆文档，是不行的。即使是你要给文档，也要给岗位职责说明、岗位操作手册等等有针对性的文档。而不是就给他一个员工手册就完之大吉。但是制定这样的有针对性的文档确实不是好注意，因为你和工厂不一样。他们的生产是稳定的，你可以制定一份文档使用很久，而且给好几个同样职责的岗位使用。而在软件生产中，你显然无法做到这一点。
首先我们来分析 zcwhgj(open-minded) 提到的那种情况－－AB两者不同的接口问题。
首先我想应该在概要设计的时候就定义好成员间的接口，这个接口是公开的透明的。修改这个接口是要按照修改需求那样通过一定的手续的。其实概要设计最重要的就是解决接口问题，然后就是解决任务如何分配的问题。其实概要设计如果在一个组织中，特别是在一个有一点规模的组织中，既是一种技术工作，也是一种管理工作。而且在发布这个概要设计的时候必须有设计者的答疑，这个义务至少要一直持续到项目接受。并且概要设计者要对接口做维护，任何修改建议都应该提交给它，并且在他的组织下讨论修改结果，并由他统一发布。而详细设计我还是建议大家不要做了，当然这要建立在你概要设计的粒度不能太粗的基础上。而现今的实际工作中，我想大家都看到过糟糕概要设计景象：
－》组织大家开一个会，会上决定程序要分为数据库、显示、控制、维护等等几个模块，谁谁负责一个模块。然后就下发一个概要设计文档，遵守GB或者其他格式模板的文档（就像做小学生填空题的作业的概要设计文档）。
这难道就是概要设计吗？
文档的同步问题是一个大问题，其实我们考虑这个问题可以有不同的方法。首先我们可以减少文档的量，也就是减少为达到同步而要做的工作。其次，我们要做到文档中要尽量增加内聚，减少耦合。其次抛弃过时的文档，只使用最新版本的文档。
但是无论怎样，你都应该加强你的配置管理，这是一个效果明显而持久的手段。
软件工程化就是向分工明确化努力，但是不是说分工了就是工程化了。分工必须要建立在确实的解决各个工种间的合作问题，是他们明确找到什么该是谁负责。你只提供给他一堆文档，是不行的。即使是你要给文档，也要给岗位职责说明、岗位操作手册等等有针对性的文档。而不是就给他一个员工手册就完之大吉。但是制定这样的有针对性的文档确实不是好注意，因为你和工厂不一样。他们的生产是稳定的，你可以制定一份文档使用很久，而且给好几个同样职责的岗位使用。而在软件生产中，你显然无法做到这一点。
#20
zcwhgj(open-minded)：
标准不仅是系统分析员作出的需求分析，当然对于概要设计、测试用例、用户手册确实如此。
需求分析的载体（我称为机能设计）本身就是一个中间产品。它参照的标准又是什么？
你说的“刷新速度跟不上”，其实就是信息传递不通畅了:)
用工作流来研究软件开发过程，确实是一个有效的方法。
《统一软件开发过程》这本书就是这么做的。这本书是rational三剑客合写的，相当不错，建议参考。
但是这样研究涉及的东西比较多，比较复杂。
像我这种头脑简单的家伙就喜欢剔除一些杂乱的东西——人性、情趣、环境等等，就抓住抽象数据流转来讨论。
等熟悉了骨架之后，再专心整理其上的皮肉……
标准不仅是系统分析员作出的需求分析，当然对于概要设计、测试用例、用户手册确实如此。
需求分析的载体（我称为机能设计）本身就是一个中间产品。它参照的标准又是什么？
你说的“刷新速度跟不上”，其实就是信息传递不通畅了:)
用工作流来研究软件开发过程，确实是一个有效的方法。
《统一软件开发过程》这本书就是这么做的。这本书是rational三剑客合写的，相当不错，建议参考。
但是这样研究涉及的东西比较多，比较复杂。
像我这种头脑简单的家伙就喜欢剔除一些杂乱的东西——人性、情趣、环境等等，就抓住抽象数据流转来讨论。
等熟悉了骨架之后，再专心整理其上的皮肉……
#21
多谢zhaoxichao(小西)指点。
其实关于信息的丢失和歧义，正如ozzzzzz(希望敏捷)所说，是无法避免的。
我想做的是如何减小信息的丢失和歧义到可以接受的范围。
而软件工程的明确分工问题，我倒是非常感兴趣。
我一直认为高耦合的工作一定要分给一个工作单位做。
这里的工作单位按照规模不同，可以是一个部门、一个小组、一个人。
可以把一部分功能分给一个部门，把一个组件分给一个小组，把一个模块/类分给一个人。
分配任务只需要给工作单位提供接口定义、功能说明、约束条件，其他的就让他们自己发挥吧。
呵呵，这只是我自己的一些感悟，希望前辈们指正！
其实关于信息的丢失和歧义，正如ozzzzzz(希望敏捷)所说，是无法避免的。
我想做的是如何减小信息的丢失和歧义到可以接受的范围。
而软件工程的明确分工问题，我倒是非常感兴趣。
我一直认为高耦合的工作一定要分给一个工作单位做。
这里的工作单位按照规模不同，可以是一个部门、一个小组、一个人。
可以把一部分功能分给一个部门，把一个组件分给一个小组，把一个模块/类分给一个人。
分配任务只需要给工作单位提供接口定义、功能说明、约束条件，其他的就让他们自己发挥吧。
呵呵，这只是我自己的一些感悟，希望前辈们指正！
#22
多谢ozzzzzz(希望敏捷)版主的提醒！
“我们不应该也不能以文档为中心，而应该以文档的使用为中心。”
呵呵，在讨论中不知不觉就从文档的选取运用滑到文档本身了:P
“我们不应该也不能以文档为中心，而应该以文档的使用为中心。”
呵呵，在讨论中不知不觉就从文档的选取运用滑到文档本身了:P
#23
任何形式的信息流转都是可以的，问题是源和目的理解的应该一样就可以了。统一标准当然是一种有效的方法，但是并不是非常有效。因为标准制定者和使用者的差距较大，使用者之间也有差距，这样标准本身的内容就会带来不利于信息流转的因素。个人认为统一一个团队内部被接受的标准就可以了。但是这样做对描述信息的人的要求很高。抓重点，还要说清楚，不太容易。
#24
再次沉底……
T_T
BinaryTreeEx(狂徒)你有些误解了。我的意思就是制订一个自己（团队内部）的标准。所谓统一，指的也是团队内部的统一。
向大家推荐一个网址：http://www.iturls.com/TechHotspot/TH_DocEng.asp，是有关Document Engineering的。努力学习中……
顺便再向大家推荐一篇文章：http://www.iturls.com/Expert/doc/modlref.pdf，《从软件的"胚"谈到模型的参照系》。是关于uml china上的一个讨论的文章，感觉挺有意思的:)
T_T
BinaryTreeEx(狂徒)你有些误解了。我的意思就是制订一个自己（团队内部）的标准。所谓统一，指的也是团队内部的统一。
向大家推荐一个网址：http://www.iturls.com/TechHotspot/TH_DocEng.asp，是有关Document Engineering的。努力学习中……
顺便再向大家推荐一篇文章：http://www.iturls.com/Expert/doc/modlref.pdf，《从软件的"胚"谈到模型的参照系》。是关于uml china上的一个讨论的文章，感觉挺有意思的:)
#25
mark