Hello，时隔半年，我终于继续了 =.=
1、为什么要观察你的项目–需求的重要性。
俗话说，磨刀不误砍柴工，当开始一个项目时，我希望你就像在街上看到了美女，你要先好好打量打量，然后再思考，“啊，我怎么去问她的电话呢~”
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
2、我要观察到什么–什么是需求
“需求是产品必须完成的事以及必须具备的品质。需求存在的原因要么是该类型的产品要求一定的功能和品质，要么是客户希望需求成为交付的产品的一部分。”
–《掌握需求过程》ISBN:9787115159830
从上面的漫画中，可以很有趣的发现，由于沟通方式，对目标的理解差异和技术水平的不同，都会让需求在传递中发生变化，这种变化有时可能是致命的，我们人类在沟通时多采用语言，然而语言，尤其是口头语言，极易发生变化。因此，就需要大家对需求有一个统一的认识，什么是需求，需求应该包括哪些内容，不应该包括哪些内容，应该如何去分析需求。
本节引言中的话，严格来讲不是对需求的定义，让我们来看IEEE软件工程标准词汇表(1997年)中“需求”的定义：
(1)用户解决问题或达到目标所需的条件或权能(Capability)。
(2)系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
(3)一种反映上面(1)或(2)所描述的条件或权能的文档说明
软件需求包括三个不同的层次—业务需求、用户需求和功能需求—也包括非功能需求。业务需求( business requirement)反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例(use case)文档或方案脚本(scenario)说明中予以说明。功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性(feature)是指逻辑上相关 的功能需求的集合，给用户提供处理能力并满足业务需求。
简单来说，需求就是说明你软件将要满足的用户需要，需求是你软件的功能列表，这里的功能可能包括看得见的功能和看不见的功能。同时需要注意实际用户（用户是重要的需求分析参与者，难以想象一个只有开发者而没有用户参与的需求分析，所得出的是什么）可能对需求的理解有误，有时他们甚至不了解活无法向你描述出他的需求，也有时，他会“啰啰嗦嗦”的向你讲一堆不是需求的东西。
同时，需求还包括非功能的部分，例如，“单次搜索查询必须在0.1秒内完成”、“用户传输文件的速度不应低于其网络最高可用带宽的50%”，这些内容并非软件的功能性要求，但是实际上是软件的使用者使用软件体验、感受的重要感受点甚至是其是否能完成功能性需求的制约。
3、我没有马王爷的第三只眼–那么我如何分析需求呢
哦，这很麻烦，是的，好吧，我们退一步，作为开发人员，你可以让你的产品经理去和客户打交道，但是你必须和你的产品经理打交道，同时，你还必须和你的代码打交道。
与产品经理打交道和与代码打交道是两码事，八杆子打不到一块，你不能和产品经理讲if(xxx) {} ，也不能去问你的代码，这里是让用户操作的，还是你丫自动操作的。
在与产品人员打交道时，你有责任用他们的语言来描述问题，这并不是单纯为了对方能够听懂你说什么，更重要的是，这会大大减少你们在交流沟通中的误解。所以，熟知你所在的行业，熟悉他们的业务，如果你要开发财务系统，请去阅读财会相关书籍，如果你要开发ERP系统，请去和工人师傅、基层管理人员多聊聊，在拓展你领域的同时，也会让你对你的编程思想有新的看法。
在与代码打交道的时候，你需要是一个好的建筑师，你应当构建严谨、运行健壮、可扩展性强的代码，这要求你在充分理解需求的情况下，看到需求的发展方向以及需求中可能发生变动的情况，甚至你需要和产品经理、客户去沟通，提出你的想法，当你问道“我觉得这里这样做的话，系统可能存在不稳定的因素，如果怎么怎么样做，不仅系统稳定了，您的操作也会更方便”，客户恍然大悟，你又减轻了工作量，何乐不为呢。
在理解需求、分析系统时，我建议你首先这样做：
将系统中存在的活动者都列出来，然后依次列出他们的操作功能和反应。
比如，一个简单的文章系统，我们可能这样去描述它
普通用户：注册、登录、找回密码、修改个人信息、查看类别、查看文章、查看某个类别下的文章、输入关键字搜索文章、发表评论、当别人发表对自己评论的回复时收到邮件。
管理员：查看用户信息、CURD（Create-Update-Read-Delete）类别、CURD文章
在上面的需求描述中，涉及了两个活动者，分别是“普通用户”和“管理员”，同时两个活动者都有若干功能，其中“普通用户”的“当别人发表对自己评论的回复时收到邮件”实际上不是用户的主动操作，而是用户对某个操作的反应，需要注意的是，这样的信息也需要在需求分析中体现。
需求分析可以体现为UML用例图，其好处是更直观，同时由于是统一化的表达，更有助于沟通，其他程序员可以更方便的理解你的意思，而不容易出现理解误差。
关于UML用例图方面的内容，可以到http://hi.baidu.com/jyangstu/blog/item/5d2f89131ef270c6c3fd7833.html查看一份简介。
我的需求方法实际上是用例图的一个超级简版，这个方法不能体现活动者与活动者、用例与用例（就是活动者所做的那些事情）之间的关系，一般适用于小型项目或大中型项目的模块级需求分析，对大中型项目的整体需求分析，实际上是一个非常复杂、有机结合的多个过程的系统，以后有机会我们再探讨。
Web服务器端技术
PHP, 听小韩聊PHP项目开发