项目方案咬文嚼字
没有真正意义上使用过UML，偶然看到IBM开发社区上的一篇文章思路很顺。就想着整理到博客中来。
原文地址：http://www.ibm.com/developerworks/cn/rational/10/using-stakeholder-collaboration-strategy-with-requirements-composer-part1/
以下是根据原文和网上其它文章自己梳理的内容：
为以后写项目报告中积累点资料。
典型的商业系统涉及的领域：
-提供业务服务组件（ESB、SOA）
-相对独立的财务管理（ERP）
-资产方面设备维护和物流支持（ITIL、GIS+GPS）
-行政。。。未知
-监察。。。未知
-办公自动化商务流程（OA）
-决策支持（DSS）大学学的出来工作后未见到一个像样的
软件是什么：
是辅助工具。符合需求（业务需求），解决问题（业务目标）。
软件开发过程：
了解领域的业务概况和业务目标。
-潜在的问题：
在方案生命周期分析，定义和交流需求，是一项非常复杂的任务，它涉及到了很多的领域。可以导致很多的问题
业务与 IT 没有得到适当的安排，所以项目可能就不能交付预期值了
原始意图，内容以及规格的背景可能被误解
完全基于文本的文献很难理解
涉众在决策时不能访问完整的信息
涉众在评审时会误解文献，因为文献巨大的数量，缺乏可视性技术，非目标的内容，缺乏清晰的场景或者背景。
需求作者可能会从评审那里得到大量的回馈信息，这样就会十分的困难及耗时。
不健康的项目会经历不清晰的查看，不频繁的交流，以及处理不正确假设的团队
当涉众没有理解提供的工件，或者不把它们当做自己的责任时，需求作者就不会接受回馈信息，或者接受不足够的回馈信息
开发者不能轻松理解或者分清需求内容
团队在交流方面可能存在地域分布太过分散的困难
想要交流更改的团队发现想法很难沟通
不同的基础形成了协作以及定义可理解需求的障碍
-造成的影响：
创建了其他的工作以指定，设计，开发和测试系统。
当涉众不能访问工件时可能的再使用和生产力会丢失掉
涉众不会交付回馈信息，因为找到相关的工件是很困难的
涉众并不是总是交付回馈信息，或者交付高品质的回馈信息，因为理解需求是很困难的
当测试员不能找到相关的信息时，他们不能轻松促进测试
地理分布的项目生产效率低下，成功几率降低
对业务的变更和响应性受限制
大量高成本受控的需求会扰乱可能提供的业务价值
方案的晚期交付性
更高的成本
降低的品质以及不能向业务交付预期价值的方案
降低的信任感，并且损害了业务与 IT 单元之间的关系
降低了IT的可信度以及信誉
-成功的方案带来：
有助于需求分析，定义，确认和方案生命周期内涉众之间的协作交流。
更好地理解涉众的需求，并使得涉众就促进方案开发达成一致意见，该方案会向业务涉众交付价值。