|
原则一：将大项目分成若干里程碑式的重要阶段，各阶段之间有缓冲时间，但不进行单独的产品维护。
微软通常采用“同步－稳定产品开发法”。典型项目的生命周期包括三个阶段： 计划阶段：完成功能的说明和进度表的最后制定
开发阶段：写出完整的的源代码
稳定化阶段：完成产品，使之能够批量生产（Roll Out） 这三个大阶段以及阶段间内在的循环方法与传统的“瀑布”（Water Fall）式开发方式很不相同，后者是由需求、详尽设计、模块化的代码设计与测试、集成测试以及系统测试组成的。而微软的三个阶段更像是风险驱动的、渐进的“螺旋”式的生命周期模型。
在开发和稳定化阶段的所有时间中，一个项目通常会将2/3的时间用于开发，1/3的时间用于稳定化。这种里程碑式的工作过程使微软经理们可以清楚地了解产品开发过程进行到了哪一步，也使他们在开发阶段的后期有能力灵活地删去一些产品特性以满足进度要求。
计划阶段
这里我总结了一下，主要是做以下事情 1.把你准备做什么样一个产品搞清楚，这个产品有什么特性 2.这个产品有没有市场，用户为何需要这个产品，已经该产品的走势 3.这个产品大概是个什么样子，是否有个大概的原型展示方便高层决策 4.设计的功能，目标，优先级，大概的进度。
所以微软指的这个计划阶段包括了很多可行性研究和产品规划的内容在里面，更多的是一个产品规划的内容。
开发阶段
开发阶段的计划对三四个主要的里程碑版本都逐个分配一组特性，规定出特性的细节和技术上的相关性，记录下单个开发员的任务以及对进度的估计。在开发阶段中，开发员在功能性说明的指导下写源代码，测试员写出测试项目组以检查产品的特性与工作范围是否正常，用户教育人员（User Education）则编写出文档草案。(参考微软的MSF模型)
当测试员发现错误时，开发员并不是留待以后处理，而是马上改正，并在整个开发阶段内使测试不断地、自动地进行。这就改善了产品的稳定性并且使版本发布日期更易估计。当达到项目中的一定阶段点后（40%时），开发员就试图“锁定”产品的主要功能要求或特性，从此只允许小范围的改动。如果在此点之后开发员想作大的改动，他们必须与程序经理以及开发经理进行讨论协商，也许还要征求产品部门经理的意见。 (这里有两点，一个是提倡及早的发现缺陷和持续的集成，一个是后期严格的对需求变更进行控制）
一个项目是围绕着3或4个主要的内部版本，或“里程碑子项目”来组织开发阶段的。一般用2至4个月来开发每一个主要的里程碑版本。每个版本都包括其自身的编码、优化、测试以及调试活动。项目为意外事故保留总开发1/3的时间，即“缓冲时间”（Padding Time）。 (应该所1/3时间是足够多的，一般研发项目很难预备这么足够的Buffer)
当对最后一个主要的里程碑版本做了测试与稳定化之后，产品就要进行“外观固定”（UI Freeze），即确定产品的主要用户界面，如菜单、对话框以及文件窗口等。此后有关用户界面将不再进行大的改动，以免引进同步修改相应文档的困难。
稳定化阶段
稳定化阶段着重于对产品的测试与调试。项目在此阶段尽量不再增加新的功能，除非是竞争产品或者市场发生了变化。稳定化阶段也包括了缓冲时间，以应付不可预见的问题或者延迟。在软件的开发流程中，软件的测试与开发是一种“矛与盾”的关系，互为补充，缺一不可。在微软，可能这种关系发挥到了极至：有时开发部门与测试部门互相较着劲，开发经理和测试经理的地位是相同的，有时甚至测试经理的地位甚至凌驾于开发经理之上，但他们之间没有根本的利益冲突，只有一个共同的目标：将产品的质量提高。
在微软内部有专门的SLM源代码管理工具，负责管理源代码和自动构建。开发人员每天在下班前将自己的代码Check In,SLM由预先定义好的脚本进行自动编译。第二天测试人员再下载前一天的Build进行测试。将测试的情况及时的反映到另外一个工具软件中,可以根据这个工具查询哪个开发员当天的BUG活动的、解决的数量，哪个测试员的BUG质量数目等等一些基本的产品质量情况，这样项目经理可以很容易的掌握该项目的具体进展情况。还有项目经理可以根据这个工具，及时的掌握、了解每个测试员和开发员的工作状态，这一点也很重要。(微软的源代码管理和每日构造和持续集成机制是很值得推广的地方)
微软也许正是靠着“程序员的聪明和测试员的勤奋”构建起软件帝国的大厦、谱写着软件事业的辉煌。
原则二：运用想象性描述和对特性的概要说明指导项目
编写想象性描述和概要说明
为了给出足够的开发框架以使工作能持续进行，并且能容纳开发过程中出现的变化并保持足够的灵活性，微软采用想象性描述和概要的说明来指导项目开发，而不是在一开始就努力写出一份完整和详细的说明。所谓想象性描述是由程序经理和来自市场营销组的产品计划人员共同编写的一份非常短的文件，在其中主要是定义产品开发的目标（不涉及产品的具体细节！）。通常对一个全新的产品，想象性描述一般会相对较详细，在其中还含有一份粗略的说明文件。总的来说，微软对于想象性描述的要求是：
越短越好，尽量说明"产品不做什么"(而不是"产品要做什么"！)。
运用想象性描述，程序经理开始编写功能说明文件，该文件解释产品的特性是什么以及这些特性如何与其他特性及产品发生关系。最初它只是一个概要性的说明文件，随着项目的进展，程序经理会随时向其中添加更多的细节，最终的说明文件将变得象用户手册一样。完整的说明不只起着对产品最新功能的描述作用，而且它还是在产品投产与发货之前进行测试与评估的主要依据。
想象性描述有助于决定删除哪些特性。
微软内的各个开发组采用想象性描述帮助细化产品版本的规定主题，然后以此主题来决定是否需要增加产品各个可能的特性。通常不要轻易改变所确定的主题，否则可能造成产品开发上的混乱。
编写说明文件
说明文件在产品小组的所有成员之间、产品小组之间以及产品小组与管理部门之间起着传递产品的设想与要求的作用。在说明文件中必须清楚地描述产品特性（描述每个特性如何工作，外观如何以及从用户的角度出发如何与用户交互。如果特性有一个界面，还应包括一张示意图，以显示出界面的效果），并赋于其相应的优先级。程序经理据此建立起项目的开发进度表。此外在其中还应包括以下各项内容：用一句话表示的项目开发目的，关于产品是什么与不是什么的清单，对顾客的定义，对竞争产品的定义，产品对系统的要求（包括操作系统版本、最小内存要求、硬盘空间、处理器速度以及显示器分辩率），对第三方（如打印机驱动程序、组件）的任何依赖性。程序经理负责协调并"写下"说明
程序经理（Program Manager）应考虑以下问题： 这项特性的要点是什么？
用户如何使用该特性？
这项特性有意义吗？
该产品中或微软的其他产品中有类似的特性吗？
有哪些问题被遗漏了？
组内的交流令人满意吗？
最终程序经理通过与组内开发人员的共同讨论决定有关特性的内容，并将其写下来。
构造原型
构造原型是程序经理具体说明一件新产品或一个新版本的最好方法，这从许多方面来说都使开发前测试成为可能，尤其在可用性方面，并且有助于对与用户交互情况作出好的理解，它也能使产品说明更紧凑。
微软的开发人员通常采用VB构造用户界面原型，但是对于构造计算机屏幕模型之类的工作，画笔（Paint brush）也是一个很好用的工具。死板的说明变成有生命的文件，说明不应过于详细以至限制了发明创造。在项目开发过程中，说明文件的早期版本会有相当大的增加与改变。由于说明的变动可能会导致相应开发工作的极大变动，所以微软通常是将精力首先集中于那些没有什么用户界面的特性上，因为在完成开发前不必去了解用户对它们有何反应，也就是说这些特性不大可能改变。然后再面对其它特性。但是当产品开发到一定程序后，例如40%之后，程序经理必须严格控制对特性的修改（主要是指增加新的特性），否则不光会造成开发延迟，而且会压缩可用的测试时间。
(做一个新产品的时候，刚开始是根本无法想清楚很多细节特征的。确实可能只有一个框架性的概念。所以微软应该也是很强调迭代开发和逐步细化，强调通过原型进一步细化设计.所有这也是原型为何在挖掘用户深处需求的时候有重要作用的原因，用户刚开始可能也不清楚要哪些细节性的功能，当用户看到原型后才能够提出深层次的一些需求来)
原则三：根据用户行为和有关用户的资料确定产品特牲及其优先顺序
对于一个开发项目而言，如何确定最终产品中应包含什么特性通常是比较困难的一件事。为此微软采用了一个称之为“基于行为制定计划”的方式来进行特性选择与优先级安排。
基于行为制定计划法从对用户行为，诸如写信或做预算，做系统研究开始。然后，根据某一特性在支持重要的或者是经常的用户行为上的程序对其进行评价。这样做的优点是对特性取舍更具理性：讨论对顾客想要做什么加以更好的安排，对某个给定特性是否方便了特定任务的更集中的辩论，可读性更强的说明，以及在市场营销、用户教育和产品开发中更好地同步。
特性选择和优先级安排中的基于行为制定计划
基于行为制定计划法中的关键点在于按用户行为、产品特性以及行为和特性之间的内部联系来分析产品。程序经理和产品计划者把产品试图支持的用户任务或方案分成大约20个“行为”，然后他们努力把行为（以及任何子行为）映射入微软的现行特性和竞争对手产品的特性中去。他们也把行为映射到不同的顾客形象或不同的市场部分中去。
当说明产品的新版本时，基于行为制定计划法帮助程序经理和开发员集中他们的精力与创造力。象 Excel之类的项目，争取在每个新版本中加入的主要行为不超过四个。绝大多数特性直接映射入这些行为之中。该做法使项目可以按特性对用户的价值来进行分级。通过分级，促使程序经理和开发人员都行动起来，使他们的特性支持尽可能多的行为。这种良性竞争对于用户有益，同时也利于提高生产率。
(这个原则充分的体现了微软产品完全由用户驱动，软件创造客户价值)
由于基于行为制定计划法是从整个产品的观点着眼，因此有助于在不同职能上工作的项目成员理解产品做什么，以及其他产品的相应特性如何可能支持那些需要或不需要其他应用软件产品的行为。
原则四：建立模块化的和水平式的设计结构，并使项目结构反映产品结构的特点
微软产品设计中的一个关键概念是产品的基础结构（Infrastructure），尤其是生命周期短的应用软件，应随项目的进展变得更加单一（而不是错综复杂）。当开发组构造产品的第一版时，他们更多地使用分级式结构，好为产品设计规定出一个最初的架构。随着时间推移，他们向单一的结构迈进，以使项目能集中于特性开发。微软越来越强调不同产品间的特性共享。共享有助于使不同产品的“性能与感觉”（Look and Feel）都统一协调起来；它也方便了需要不止一个应用软件的用户，减少了代码的重复书写，缩小了单独一个应用软件的规模。
微软用特性小组组织产品开发，这种方法使得每个人都容易明白小组是如何与整个产品相关联的。项目从规定概要说明开始。概要说明的形式是一份已确定了优先级安排的内容清单，涉及产品下一版本将要开发的相对独立的特性，以便由分开的特性小组加以开发。
程序经理和开发员把项目分成特性子集，再将之分配给每个特性小组，让他们在3到4个主要的内部项目里程碑中进行生产。这种产品组织与开发方法使微软能靠简单地增加开发员和创建一个大的小组来渐进地增加产品的功能。
把特性(与函数)作为开发单位
微软软件产品的特性是用户最终可见的相对独立的功能单位，就如建筑材料一般，对应用软件产品更是如此。系统软件产品，如NT或者95的特性，对最终用户通常不直接可见。微软和其他公司有时简单地称这些不直接可见的特性为“函数”。
程序经理承担开发一组特性或函数，实现从说明经测试、文档化直到最后完成的过程。他们必须与开发员合作，后者负责估计进度表与完善每个特性。开发员还要在一台联网开发计算机上存储一到几个文件，用以保存特性的程序源代码。大多数特性的开发与改进只要一名开发员，而有的大型特性则要一个小的小组。
(感觉有点类似于特征驱动的开发，要做好每日构建功能点的拆分一定要足够细)
产品结构是决定其长期结构完整性的基石
产品结构是产品内部的基干，它规定了重要的结构构件以及这些构件如何组装到一起。产品结构及用于组装结构的构件，提供了实现产品特性（即做详细设计与编码）的支柱。产品的结构对最终用户而言，通常并非直接可见。只有结构要实现的特性是可见的。产品结构也是决定产品长期结构完整性的基石。产品功能的任何改变都不应造成潜在的产品结构散架。
产品的层次结构
对于产品，也可以采用层次结构的方法加以分析。通常定义良好的层次结构有助于对产品特性进行灵活的增加、删除与改进。此外良好的层次结构有助于产品在不同平台上的移植。（例如Excel总共定义了五层，其中只有最底层的操作系统层是与平台相关的，其它各层均是通过调用其下层所提供的API接口加以实现的，所以其移植极其方便。而在Windows 95中通过“虚拟机”的概念实现了对16位、32位以及DOS程序的支持。）
小的结构文档：源代码是唯一文件
除了API文档，微软不对其产品结构生成相应的文档，虽然有时高级开发员可能会写下高层结构。对复杂的特性，许多开发员在某些点记录并复查特定于他们所负责的结构细节，但此工作是可选的，并不强制执行。除了源代码文件与特性说明，为数不多的组为新程序员准务了描绘某层结构的文档（主要的数据结构，如何工作等等）。但是这些文件并不时常更新，经理们也不要求项目组生成此类内部文档。在有关的说明文件中，并不涉及实现问题。开发员应该知道如何去实现，或者能够去学会。记录的关于结构的文档如此之少是因为“一个开发员的工作是编写我们要卖的代码，而不是花时间写高水平的设计文件”，“设计文件不应与源代码分离”。分割代码与“保持事情的简单”。(源代码就是设计)
特性小组和作为"内容专家"的小组领导
特性小组一般由一个领导和3至8名开发人员组成，工作于相关的特性领域。小组的规模常常视小组领导的经验和能力而定。特性小组领导向项目开发领导汇报并负责项目的全部开发工作；而项目开发领导则拥有对产品的更为全局性的观点，从而最有可能发现不互相关联的问题。在特性小组中的每个人均是此领域的“专家”，他们了解如何使用产品、了解竞争对手的产品、了解未来将向何处去。通常为便于交流，提高软件的组织结构（软件倾向于映射出构造它的组织的结构），应保持特性小组的小规模。(不在于小组的人数，而在于小组成员的整体技能不能差别太大)
原则五：靠个人负责和固定项目资源实旋控制
对于软件项目而言，精确估计产品的开发与交付进度是很困难的。对此微软采取的方法是将进度安排和工作管理的责任推到最底层，即单个的开发人员和测试人员那儿去。这保证了每个人除了作为小组的一部分外，还负有个人的责任。单独的开发人员设立他们自已的进度表，程序经理把单独的进度表汇总起来，再加上缓冲时间，以制定出一个全面的项目进度表。顶层的总经理也固定人员与时间等基本资源，以确保项目集中并限制其努力与创造程序。 关键的目标，尤其对应用软件，是指明产品的目标出品日并争取尽可能长久地坚持它。程序经理和开发员从出品日回溯，规定中间的项目里程碑的日期。这个“固定的出品日法“的中心在开发员身上。以避免因为项目没有固定的结束点，导致在最终无用的设计、再设计和测试的循环中消耗一年或更多的时间。
开发人员做出他们自已的进度估计
“日期设定方法"。但是开发人员一般会做出较乐观的估计，因此开发经理还需对他们所提供的日期进行调整并加上缓冲时间以避免因因信息不完全而出现的问题。微软这种制定进度的方法的优点在于：它从人们那儿得到更多的合作，因为日期是自已定的，不是经理定的；进度总是富有进取性，因为开发人员不可避免地会低估他们真正需要的时间。
对细致的任务的进度估计
微软的第二个进度安排方法是：对要完成的任务做非常详尽的考虑，在此基础上请开发人员给出他们对“实现”的估计，以此力图“促使”更加现实主义并避免过度低估。
通常微软把任务细化到4小时（半天）到3天之间。对于准确进度的安排，微软的经理是这样认识的： “任何任务只要超过一星期，那人们就一定没有充分地全盘考虑它。任何任务某人估计只用少于半天就可完成，则他对它考虑得太多了。他应该用更多的时间去编程，更少的时间来考虑”。对于类似类于Windows NT之类的操作系统而言，进度安排更加困难，对其一般以几天或者半周为工作单位进行进度估计。
安排开发人员与小组进度时的心理学
当项目变大时，微软把员工分成小组。然后经理把进度的责任和所有权尽可能地分发下去，直到小组和个人；这使二者都产生了一种拥用工作的感觉。它还在小组中，个人中，尤其是小组领导中造成强烈的跟上其它同事预计进度的压力，因为经理可能再平衡进度，从落后的小组或个人手中拿走工作。这样，同事间的压力使经理不需要太多的努力就可以对个人或单个小组的进程实施严格控制。(厉害)
"固定的"出品日(RTM: Release To Manufacture)
为了把创造力约束在时间限制之中，微软现在在新产品或者产品新版本开始前争取固定出品日，至少是有出品日的内部目标。这给人们施加砍去特性和集中在一个项目上的压力，逼迫他们去苦苦思考应将哪个新特性加入产品中。虽然最终产品的交付目标可能是由高级执行人员设定，但是开发人员与小组仍然设定他们自已的进度表。
微软一般根据预先的时间进度的大致估计出一个RTM日期，然后向前回溯相应的各个 Milestone日期，如RC、Beta、Tree Lock、UI Freeze、Feature Complete以及CC（Code Complete）等等各个Milestone的相应日期。制定出十分详尽的产品研究开发时间进度表，产品开发组的各个成员以这个进度表为目标统一协调工作。
微软十分强调软件开发过程中的Teamwork Spirits，这种理念贯穿在微软各个产品开发的各个阶段。这也是微软得以成功的一个十分重要的原因。
需求分析的20条法则
对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。
经理：“我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。”
分析员：“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”
经理觉得奇怪：“我不是刚告诉你我的需求了吗？”
分析员：“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。”
经理：“业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”
分析员尽量解释从用户处收集需求的合理性：“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”
经理坚持道：“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。”
风险躲在需求的迷雾之后
以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见——需求分析奠定了软件工程和项目管理的基础。
拨开需求分析的迷雾
像这样的对话经常出现在软件开发的过程中。客户项目经理的需求对分析人员来讲，像“雾里看花”般模糊并令开发者感到困惑。那么，我们就拨开雾影，分析一下需求的具体内容：
·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。
·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。
·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。
·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。
·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。
前面提到的客户项目经理通常阐明产品的高层次概念和主要业务内容，为后继工作建立了一个指导性的框架。其他任何说明都应遵循“业务需求”的规定，然而“业务需求”并不能为开发人员提供开发所需的许多细节说明。
下一层次需求——用户需求，必须从使用产品的用户处收集。因此，这些用户构成了另一种软件客户，他们清楚要使用该产品完成什么任务和一些非功能性的特性需求。例如：程序的易用性、健壮性和可靠性，而这些特性将会使用户很好地接受具有该特点的软件产品。
经理层有时试图代替实际用户说话，但通常他们无法准确说明“用户需求”。用户需求来自产品的真正使用者，必须让实际用户参与到收集需求的过程中。如果不这样做，产品很可能会因缺乏足够的信息而遗留不少隐患。
在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。
优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系。
由于项目的压力与日俱增，所有项目风险承担者有着一个共同目标，那就是大家都想开发出一个既能实现商业价值又能满足用户要求，还能使开发者感到满足的优秀软件产品。
客户的需求观
客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。
1、
分析人员要使用符合客户语言习惯的表达
需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。
2、分析人员要了解客户的业务及目标
只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。
3、
分析人员必须编写软件需求报告
分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。
4、
要求得到需求工作结果的解释说明
分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。
5、
开发人员要尊重客户的意见
如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。
6、
开发人员要对需求及产品实施提出建议和解决方案
通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。
7、
描述产品使用特性
客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。
8、
允许重用已有的软件组件
需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。
9、
要求对变更的代价提供真实可靠的评估
有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。
10、
获得满足客户功能和质量要求的系统
每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。
11、
给分析人员讲解您的业务
分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。
12、
抽出时间清楚地说明并完善需求
客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。
13、
准确而详细地说明需求
编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。
在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。
14、
及时作出决定
分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。
15、
尊重开发人员的需求可行性及成本评估
所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。
16、
划分需求的优先级
绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。
在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。
17、
评审需求文档和原型
客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。
更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。
18、
需求变更要立即联系
不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。
19、
遵照开发小组处理需求变更的过程
为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。
20、
尊重开发人员采用的需求分析过程
软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。
“需求确认”意味着什么
在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”
这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”
同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”
这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。
对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。
需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。
| 
|EaBIM网
( 苏ICP备2020058923号-1 ) 
苏公网安备32011502011255号
IP卡
狗仔卡
发表于 2014-1-13 17:18:30
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
微信
收藏
转播
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
发表于 2016-3-17 10:24:09
楼主
发表于 2015-2-3 10:00:17
