灵犀物润

谈智能家居，当我们谈起它的时候我们到底在谈论什么？归根到底，它就是一个消费类电子产品，这也是为什么许多公司决定去参加国际消费电子展的原因。智能家居是一个比较笼统的词语，它不是指的是某个具体的产品，了解的它的人一般都将其理解为一个系统，一个以人的家庭生活为中心的多设备参与的系统，通常这个系统会有一个指挥中心，也可以理解为智慧中心。

写作的过程也是一个再次强化输入的过程，使得你对以往通过阅读得到的知识有了更深入的吸收，西方有句话：“我们吃下什么，我们就会长成什么样子”，我们吸收的东西，会反过来影响我们的世界观，价值观，人生观，写作和阅读这两个相辅相成的过程决定了我们的内心世界的新陈代谢，只有通过良好的输出，我们才能将这些吃进去的变成我们自身的一部分，才能去吃下去更多的东西。

软件项目中的需求获取技巧不计其数。事实上，项目团队不可能只采用一种需求获取技巧。现实生活中总是有很多类型的信息等待我们去发现，但不同的项目干系人表述信息的方式却不尽相同。可能某个用户能够清晰地表述其使用系统的方式，但如果你想以同样的程度理解另一个用户如何完成她的工作，也许得靠你仔细观察了。获取技巧包括引导活动（期间与干系人互动以获取需求）和独立活动（期间独立工作以发现信息）。引导活动主要聚焦与发现业务和用户需求。由于用户需求包含用户要用系统完成的任务，因此很有必要与用户直接合作。而为了获取业务需求，你要

一个人如果没有足够的培训、指导和丰富的经验，不要指望他能够为一名合格的分析师。他们无法胜任这个工作，并且很快他们就会沮丧万分。这份工作包含很多“软技能”，偏重于人儿非技术。分析师需要熟知各类需求获取技巧，提交信息的方式要多种多样，不止局限于自然语言文本形式。高效率的业务分析师是多面手，不仅具备超强的沟通、引导和人际交流技能，还需要具备这个工作所要求的渊博的技术和业务领域知识，得有人格魅力。耐心并且真诚地希望与他人合作是成功的关键要素。1、倾听技巧要想成为双向沟通专家，就要学会如何有效倾听。主动倾听要

分析师必须首先理解项目的业务目标，然后定义出用户、功能和质量需求，让团队进行估算和计划项目，最后设计、开发和验证产品。业务分析师同时还是领导者和沟通者，负责将模糊的客户理念转换为清晰的规范说明，指导软件开发团队的工作。作为业务分析师，可能要执行下面描述的典型活动。...

软件项目管理方法与项目需求流程紧密相关。项目经理应当根据需要实现的需求，规划项目时间表、资源以及做出承诺。另一种策略是将开发周期纳入“时间盒”，即团队估算出他们在固定迭代时间内能够完成的工作范围。敏捷开发项目采用的就是这种方式。范围可以在计划时间范围内协商。这样一来，范围蔓延就成了“范围选择”，产品负责人可以按其意愿提出要求，但是必须为这些要求排定优先级，当团队开发时间耗尽时则停止开发。然后团队再为余下的需求制定下一个发布计划。1、选择一个合适的软件开发生命周期组织应当根据不同的项目类型以及需求的不

一旦手上有最初始的需求，就必须做好准备应对变更，因为在整个开发阶段，客户、管理层、市场、开发团队或者其他人都会不可避免地提出这方面的要求。有效的变更管理包括提出变更、评估潜在成本及其对项目影响以及确保恰当的干系人可以判断要采纳哪些变更，并做出明智的业务决策。拥有良好的配置管理实践是进行有效需求管理的一个前提条件。可以使用代码版本管理工具来管理需求文件。最好将需求放在需求管理工具中，里面提供的很多功能可以帮助你完成这些实践。1、建立一个需求变更控制流程与其抑制所有变更或者奢望变更不会出现，不如接受

验证能够保证需求的正确性、展示期望的质量特性并满足用户需要。有些需求读起来似乎没有什么问题，但当开发人员着手工作时又会遇到模棱两可或遗漏的地方。要想使需求成为设计、最终的系统测试以及用户验收测试的可靠基础，就必须修正这些问题。1、需求评审需求的同行审查，特别是称为“审查”的严格评审，是一种高回报的质量保证实践。组织一个小的评审团，让他们从不同的视角（分析师、客户、开发人员、测试人员）仔细审查需求文档、分析模型以及相关的缺陷信息。需求开发初期的非正式评审也很有价值。训练团队成员高效地评审需求并在组织中

需求规范说明的精髓就在于用一致的、可存取、可评审的方式记录不同类型的需求，且目标读者都理解这些规则。可以在一个愿景和范围文档中记录业务需求。用户需求通常表现为用例或用户故事的形式。详细的软件功能和非功能需求都被记录在软件需求规范说明书或者其他替代品中，例如需求管理工具中。1、使用需求文档模板在组织中使用标准模板来记录需求，模板所提供的标准结构可以用来记录与需求相关的各类信息。及时不用传统的文档形式存储需求，模板也能提醒你还有各类的需求信息有待发掘和记录。2、明确需求来源为了让所有干系人了解每

1、为应用环境建模系统环境关系图是一种简单的分析模型，展示的是新系统如何适应其环境。它定义了开发中的系统与外部实体（例如用户、硬件设置或其他系统）之间的界限以及接口。生态环境图展示了解决方案中的各个系统如何相互作用及其相互关系的本质。2、创建用户界面以及技术原型当开发人员或用户对需求不太确定时，需要创建一个原型，一个部分的、可能的或者初步实现的模型，目的是使概念及各种可能性更真实一些。原型可以让开发人员以及用户对所解决的问题达成共识并有助于验证需求。3、分析需求的可行性业务分析师应当与开

1、定义产品愿景和项目范围愿景和范围文档包含产品的业务需求。愿景描述可以是所有干系人对产品的产出有一致的理解。范围界定了发布或者迭代中哪些功能应该或不应该出现。愿景与范围提供了一种参考，方便对大家所提议的需求进行评估。愿景在整个项目过程中时相对稳定的，每个计划的发布或迭代都有自己的范围。2、识别用户类型及其特征为了避免遗漏任何用户团体的需求，我们要为产品识别出不同的用户组。在使用频率、所用特性、权限级别以及经验方面，这些组别可能不同。记下他们的工作任务、态度、位置或个性，这些都可能影响产品设计。