UML面向对象建模与设计(第2版) Object-Oriented Modeling and Design with UML Second Edition
系统构思(system conception)要处理的是某项应用的起源。系统构思的目的是延迟细节实现，理解完整图景。
1.形成系统概念
多数有关新系统的思想都是对已有思想的扩展。偶尔，新系统也会大大地偏离原有系统。作者又利用下面的方法帮助发现新的系统概念：
新的功能；流水化；简化；自动化；整合；类比；全球化
2. 阐释概念
作者对优秀的系统给定了个标准，就是能回答下面几个问题：
a.应用程序是为谁而做的？就是风险承担人有哪些。用户不会主动考虑新系统，除非能帮助他们获利。作者指出：如果不能让他们参与项目，那样项目的需求就很可疑，需要重写考虑。我觉得也对，做的项目如果毫无用处，干嘛费大力气去做呢？
b.它解决了哪些问题？通过这个问题来帮助我们界定工作量，确定工作范围。
c.它会用在什么地方？是关键性软件、实现性软件、新部署的功能等等
d.何时会需要它？这里提到了2个时间：可行时间和必需时间，如果这两个时间脱节不一致了，技术人员和业务专家就得通过对话找解决方法。
e.为什么会需要它？可以做一份业务案例，包括成本、有形效益、无形效益、风险和候选方案，清晰的理解新系统的动机。
f.它是如何工作的？集体讨论问题的可行性，这里不是选择解决方案，是让我们知道该问题有方法解决。
作者通过ATM案例来说明如何回答上面几个问题。
3.准备问题陈述
回答了上面几个问题后，下面要进行需求陈述，来概述待构建系统的目标和总体方案。
需求要从用户的观点来描述系统的行为，把系统看成黑盒子。问题陈述应该描述要完成哪些事情，而不是如何实现。它应该是需求的陈述，而不是对系统架构的建议。大多数问题陈述都是模糊的、不完整的、前后不一致的甚至完全错误的，所以要经过全面分析去除那些会对系统造成不良影响的部分。
作者通过ATM案例来展示了问题陈述内容。
4. 小结
项目的第一个阶段是形成新的构思。在开发之前，先要评估系统的可行性、开发系统的困难和风险、系统的需求以及成本效益比例。这个过程，我们应该考虑到系统所有风险承担人的观点，做出必要的权衡。(开始，我是认为这些评估貌似不是开发人员应该关心的，但是想想如开发起来我们才发现这个项目不太现实，或者困难太多成本增高，再去和客户沟通就会比较麻烦了，如果前期做好这方面工作后面开发就比较顺了。)