今年的气候不太正常，11月刚露出半个脸庞，就蒙上了轻纱，天会突然变得阴暗，然后雪就降了下来。
今天晚上，又是这样的，只是，天蒙蒙有些橙色，树都被妆成了圣诞节的样子。
我希望今天是一场梦，我希望，这一年，是一场梦。
然而，不是的。
ade，dota战友，ade，加班总是没蓝的同事，ade，东来顺，ade，很多次被用记号笔画过的白板，ade，glass floor，ade，220，ade，2007。
and,never,forget,those days in dream.
Hello，时隔半年，我终于继续了 =.=
俗话说，磨刀不误砍柴工，当开始一个项目时，我希望你就像在街上看到了美女，你要先好好打量打量，然后再思考，“啊，我怎么去问她的电话呢~”
So,same as our projects.
当开始一个项目时，你应当首先审视的是项目的需求，要注意了，除非是你自己为自己闲着没事做的东西，其他的项目，都是为别人做的，怎么理解呢，我的意思是说，你项目的目的就是满足别人的需求。软件实际上是一种商品。所谓商品，就是商品是为交换而生产（或用于交换）的对他人或社会有用的劳动产品[百度百科]。请注意“对他人或社会有用”，这就是在讲，我们所编写的软件是为了满足需求而存在的，如果不能满足需求，哪怕你用了再高的技术，软件做的再漂亮，运行效率再高，都不能被称之为一款合格的软件。
为什么突然要扯这么远呢，是因为，我曾经和很多人一样，在做开发的时候，开始的时候无时不刻的都在想，这个东西有什么技术创新点，什么地方的效率会很低，应该解决，后来我听到了一句话，叫做“过早优化是万恶之源（premature optimization is the root of all evil–Donald Knuth）”，可能的确有那样一些项目，他们要求很高的效率，或者，该项目的需求者一直在询问你关于效率的问题，但是无论如何，在你什么都没有的时候，你就什么都不能做，就像你并没有一个女儿，你却时刻想着如何去打扮她一样毫无意义。
请记住，我们所编写的软件，它的第一要务是满足需求，当然，运行效率、界面美化可能是需求的一部分（非功能性需求，我们稍后会谈到），但是请将其作为需求考虑，而不是贯穿软件的全部。
关于需求，这里有一幅漫画，来源未知（提示：你可以点击图片放大）：
另外还有此图片的中文版：http://picasaweb.google.com/lh/photo/ZK59I5p5-jfsc7kl213htQ?feat=directlink
“需求是产品必须完成的事以及必须具备的品质。需求存在的原因要么是该类型的产品要求一定的功能和品质，要么是客户希望需求成为交付的产品的一部分。”
–《掌握需求过程》ISBN:9787115159830
从上面的漫画中，可以很有趣的发现，由于沟通方式，对目标的理解差异和技术水平的不同，都会让需求在传递中发生变化，这种变化有时可能是致命的，我们人类在沟通时多采用语言，然而语言，尤其是口头语言，极易发生变化。因此，就需要大家对需求有一个统一的认识，什么是需求，需求应该包括哪些内容，不应该包括哪些内容，应该如何去分析需求。
本节引言中的话，严格来讲不是对需求的定义，让我们来看IEEE软件工程标准词汇表(1997年)中“需求”的定义：
(1)用户解决问题或达到目标所需的条件或权能(Capability)。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明
软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关 的功能需求的集合，给用户提供处理能力并满足业务需求。
简单来说，需求就是说明你软件将要满足的用户需要，需求是你软件的功能列表，这里的功能可能包括看得见的功能和看不见的功能。同时需要注意实际用户（用户是重要的需求分析参与者，难以想象一个只有开发者而没有用户参与的需求分析，所得出的是什么）可能对需求的理解有误，有时他们甚至不了解活无法向你描述出他的需求，也有时，他会“啰啰嗦嗦”的向你讲一堆不是需求的东西。
同时，需求还包括非功能的部分，例如，“单次搜索查询必须在0.1秒内完成”、“用户传输文件的速度不应低于其网络最高可用带宽的50%”，这些内容并非软件的功能性要求，但是实际上是软件的使用者使用软件体验、感受的重要感受点甚至是其是否能完成功能性需求的制约。
哦，这很麻烦，是的，好吧，我们退一步，作为开发人员，你可以让你的产品经理去和客户打交道，但是你必须和你的产品经理打交道，同时，你还必须和你的代码打交道。
与产品经理打交道和与代码打交道是两码事，八杆子打不到一块，你不能和产品经理讲if(xxx) {} ，也不能去问你的代码，这里是让用户操作的，还是你丫自动操作的。
在与产品人员打交道时，你有责任用他们的语言来描述问题，这并不是单纯为了对方能够听懂你说什么，更重要的是，这会大大减少你们在交流沟通中的误解。所以，熟知你所在的行业，熟悉他们的业务，如果你要开发财务系统，请去阅读财会相关书籍，如果你要开发ERP系统，请去和工人师傅、基层管理人员多聊聊，在拓展你领域的同时，也会让你对你的编程思想有新的看法。
在与代码打交道的时候，你需要是一个好的建筑师，你应当构建严谨、运行健壮、可扩展性强的代码，这要求你在充分理解需求的情况下，看到需求的发展方向以及需求中可能发生变动的情况，甚至你需要和产品经理、客户去沟通，提出你的想法，当你问道“我觉得这里这样做的话，系统可能存在不稳定的因素，如果怎么怎么样做，不仅系统稳定了，您的操作也会更方便”，客户恍然大悟，你又减轻了工作量，何乐不为呢。
在理解需求、分析系统时，我建议你首先这样做：
将系统中存在的活动者都列出来，然后依次列出他们的操作功能和反应。
比如，一个简单的文章系统，我们可能这样去描述它
在上面的需求描述中，涉及了两个活动者，分别是“普通用户”和“管理员”，同时两个活动者都有若干功能，其中“普通用户”的“当别人发表对自己评论的回复时收到邮件”实际上不是用户的主动操作，而是用户对某个操作的反应，需要注意的是，这样的信息也需要在需求分析中体现。
需求分析可以体现为UML用例图，其好处是更直观，同时由于是统一化的表达，更有助于沟通，其他程序员可以更方便的理解你的意思，而不容易出现理解误差。
关于UML用例图方面的内容，可以到http://hi.baidu.com/jyangstu/blog/item/5d2f89131ef270c6c3fd7833.html查看一份简介。
我的需求方法实际上是用例图的一个超级简版，这个方法不能体现活动者与活动者、用例与用例（就是活动者所做的那些事情）之间的关系，一般适用于小型项目或大中型项目的模块级需求分析，对大中型项目的整体需求分析，实际上是一个非常复杂、有机结合的多个过程的系统，以后有机会我们再探讨。
他们没有关注的需求
发现现在除了JSP和.Net之外，例如php、ruby之类的，还有js，甚至css、html，都没有人讲过在企业化开发的时候，这些东西应该遵循什么样的模式，达到高可用性和对需求变动的敏捷性 。
PHP、ruby、JS可能还好一些，但是CSS和HTML这些的可重用性，和对需求变动的敏捷性，讲的太少啊了，单纯说可用性、语义性，都是针对单个来讲的，而没有谈到比如说淘宝、搜狐这样的大型网站，他的CSS和页面如何重用，这应该是一个不小的话题。
按照柱子哥的思路做东西，就发现我以前从来没有这么做过事情，也没有网上的教程或者书籍告诉过我，基本上都是在讲，一个人的时候怎么开发，也没有过多考虑需求变动导致的影响。
我相信随着当前互联网形式的进一步推动，人们会逐渐重视这些方面，同时这样一些东西可以把原来二把刀的程序员，培养成可以胜任企业开发的人员，给大型网站或者大型公司做开发，也解决了很多实际的问题
如何让读者理解
单纯告诉你去如何做，和没有告诉是一样的，因为每个人都希望固守自己之前的方式，除非你明确指出了它的缺点，并让他实际感受到他固有方式的不便和新方法给他带来的实惠。这恐怕真的得用例子来带来共鸣。