需求评估培训

《需求评估培训》由会员分享，可在线阅读，更多相关《需求评估培训（173页珍藏版）》请在装配图网上搜索。

1、Day01需求评估培训需求评估培训Agenda需求的基本概念与原理需求的基本概念与原理需求工程需求工程需求定义最佳实践需求定义最佳实践需求捕获最佳实践需求捕获最佳实践业务流程与规则分析业务流程与规则分析数据需求分析与建模数据需求分析与建模Agenda需求的基本概念与原理需求的基本概念与原理需求工程需求工程需求定义最佳实践需求定义最佳实践需求捕获最佳实践需求捕获最佳实践业务流程与规则分析业务流程与规则分析数据需求分析与建模数据需求分析与建模1）理论是实践的基础2）解决概念性的误区讨论讨论l你认为“什么是需求”？l日常工作中，遇到与“需求”相关的问题有哪些？l关于“需求”最大的困惑是什么？l以下问

2、题中，对你影响最大的是哪个？不切实际的用户需求 很多需求最终是不需要的 用户介入太少 需求不完整 需求变更频繁 软件需求的定义软件需求的定义l软件行业存在这样一个问题，用于描述需求工作的术语没有统一的定义。l对同一项需求，不同的人会有不同的描述，称其为用户需求、软件需求、功能需求、系统需求、技术需求、业务需求或产品需求。l客户对需求的定义，在开发人员看来可能只是高级别的产品概念；而开发人员的需求概念对用户来说也许就是详细的用户界面设计。l需求必须被记录成文档，这一点很重要。5对需求的不同解释对需求的不同解释lIEEE的软件工程标准术语表(1990)则将需求定义为:l用户为解决某个问题或达到某个

3、目标而需具备的条件或能力。l系统或系统组件为符合合同、标准、规范或其他正式文档而必须满足的条件或必须具备的能力。l上述第一项或第二项中定义的条件和能力的文档表达。6 注意:不要一厢情愿地认为项目涉众对需求的理解是一致的。应该事先给出定义，才能保证大家谈论的是同一个问题。需求需求导致项目失败的罪魁祸首导致项目失败的罪魁祸首l根据Standish Group对23000个项目进行的研究结果表明，28%的项目彻底失败，46%的项目超出经费预算或者超出工期，只有约26%的项目获得成功。l而在于这些高达74%的不成功项目中，有约60%的失败是源于需求问题。l也就是说，有近45%的项目最终因为需求的问题最

4、终导致失败。对不知道航行目的地的人来说，没有顺风！我们在哪里重重摔了一跤我们在哪里重重摔了一跤l在Standish Group的报告中总结了导致项目失败的最重要的8大原因中，有5个与需求相关：l不完整的需求(13.1%)；l缺乏用户的介入(12.4%)；l不实际的客户期望(9.9%)；l需求和规范的变更(8.7%)；l提供了不再需要的(7.5%)缺乏资源(10.6%),没有执行层支持(9.3%),缺少规划(8.1%)项目成功的因素项目成功的因素l用户的参与：15.9%l管理层支持：13.9%l清晰的需求描述(13.0%)；l合适的规划(9.6%)；l现实的客户期望(8.2%)；l较小的里程碑(

5、7.7%)；l有才能的员工(7.2%)软件需求曾经让我们如此狼狈软件需求曾经让我们如此狼狈参与各方都以自已角度讲述问题参与各方都以自已角度讲述问题分布式 Web Services 三层对话框 菜单条 DCOMB/S 数据交换财务计算 管理报表 工作流自动库存控制 库存报警业务线索管理 业务经线索跟踪销售月报生成 交易流数据 问题的根源是什么？问题的根源是什么？l用户说的不是他想的：用户说的不是他想的：客户提供（陈述的需求）的需求并不是真实的需求，还需要作进一步的分析，以确定客户的真正需求和期望，接下来需要澄清并重新描述。可以这么说客户在理解基础业务过程和描述自己的需求方面有很大的差异。l需求分

6、析方法有问题：需求分析方法有问题：系统开发人员使用低效的需求分析和项目管理方法。l共同责任强调不足：共同责任强调不足：对客户和提供商在项目成功的共同责任方面强调不够。优秀的团队遇到糟糕的需求优秀的团队遇到糟糕的需求l用户参与不足l用户需求扩展l有歧义的需求l镀金问题l过于抽象的需求l忽略某种用户l不准确的计划l用户参与不足用户参与不足l开发人员往往也不重视用户的参与，原因是他们认为与用户打交道不像写代码那么有趣，或者自以为已经知道了用户想要什么。l用户参与不足将导致不能在项目早期及时发现需求中的缺陷，从而延误项目的完成。l在整个项目开发过程中，开发团队必须始终与实际用户直接合作。14用户需求扩

7、展用户需求扩展l由于开发过程中需求的不断发展与增加，项目往往会落后于计划的进度并超出预算。l出现这种情况是因为没有依据对需求的规模和复杂度的实际评估来制订计划，而不断修改需求又使情况变得更糟。l问题的责任部分在于用户不断提出修改需求的要求，部分在于开发人员处理这种要求的方式。l要控制项目范围的改变：l首先应明确项目的业务目标、全局规划、范围、限制、成功标准以及产品的预计用途。l然后参考这一框架对所有新特性和需求变更进行评估。15有岐义的需求有岐义的需求l岐义表现为同一读者可以对一项需求声明作出多种解释，或者不同的读者对同一需求产生不同的理解。l岐义会导致以下几点：l涉众对产品怀有不同的期望。因

8、此最终交付的产品会让部分人感到意外。l有岐义的需求使开发人员的时间浪费在解决无需解决的问题上。l有岐义的需求导致测试人员与开发人员对产品功能的理解不同，从而使测试人员也要浪费时间来解决这些差异。l消除歧义的办法之一是让代表不同观点的人对需求作正式的检查。16镀金问题镀金问题l开发人员为产品添加了一项需求说明中没有提到的功能，他认为“用户肯定会喜欢的”。这就是所谓的“镀金问题(gold plating)”。l开发人员和需求分析员不应擅自添加特性，应该把创意和备选方案提交给客户，让他们做决定。l要避免镀金问题，就应该追溯每项功能的来源，弄清楚为什么添加该功能。17过于抽象的需求过于抽象的需求l营销

9、人员或经理经常喜欢只给出一个粗略的说明，他们希望开发人员在开发过程中充实它。l这种方式对研究性项目或需求特别灵活的项目或许管用，但是需要紧密合作的团队，而且仅限于开发小型系统(McConnell 1996)。l大多数情况下，这种做法的结果是使开发人员受挫，让客户失望。18忽略了某类用户忽略了某类用户l用户所使用的产品特性、产品的使用频率以及用户自身的经验水平不尽相同。l因此，多数产品都拥有不同的用户群。如果一开始没能找出产品的所有重要用户群，就会有某些用户需求得不到满足。确定所有用户群后，还要保证获得各类用户的需求。19不准确的计划不准确的计划l不能充分理解需求，就会作出过于乐观的估计，最终不

10、可避免地陷入超支的泥潭。l造成软件成本估算失败的最主要原因包括频繁变更需求、遗漏需求、未与用户充分沟通、需求的说明不精确，以及对需求的分析不透彻(Davis 1995)等。20优质需求过程的好处优质需求过程的好处l实现有效的需求工程过程。减少开发后期以及整个维护过程中不必要的返工并可带来极大的回报。l下面列出的好处并不能完全量化，但确实存在：l减少需求缺陷l减少开发过程中的返工l减少不必要的特性l降低改进成本l加快开发进度l提高沟通效率l控制需求范围的改变l项目更有序l对系统测试的评估更准确l提高客户和开发人员的满意度21优秀需求的特点优秀需求的特点l如何才能将好的需求规格说明与那些有问题的区

11、分开来？l这一节首先对说明中的单条需求(即需求声明)特点进行讨论，然后将介绍SRS作为整体应具备的特点。l如果想知道您的需求是否具备这些特点，最好的办法就是请几位项目相关人员仔细审阅您的SRS。不同的人会发现不同的问题。22需求陈述的特点需求陈述的特点 l每一项用户需求、业务需求和功能需求都应具备下列性质。l完整性l每一项需求都必须完整地描述即将交付使用的功能。l正确性l每一项需求都必须准确地描述将要开发的功能。l可行性l需求必须能够在系统及其运行环境的已知能力和约束条件内实现。l必要性l每一项需求记录的功能都必须是用户的真正需要，或者是为符合外部系统需求或某一标准而必须具备的功能。l有优先次

12、序l为每一项功能需求、特性或用例指定一个实现优先级，以表明它在产品的某一版本中的重要程度。l无歧义l一项需求声明对所有读者应该只有一种一致的解释，然而自然语言却极易产生歧义。l可验证性l看看您能否设计一些测试方法或使用其他验证方法，如检查或演示来判断产品是否正确实现了需求。23权利和义务法案权利和义务法案客户有权利客户有权利1.要求需求分析员使用客户的语言要求需求分析员使用客户的语言2.要求需求分析员熟悉客户的业务，了解客户对系统的目标要求需求分析员熟悉客户的业务，了解客户对系统的目标3.要求需求分析员把需求收集过程中客户提供的信息组织成书面的软件需求规格说明要求需求分析员把需求收集过程中客户

13、提供的信息组织成书面的软件需求规格说明4.要求需求分析员解释需求过程生成的所有工作结果要求需求分析员解释需求过程生成的所有工作结果5.要求需求分析员和开发人员尊重客户，始终以合作和专业的态度与客户进行互动要求需求分析员和开发人员尊重客户，始终以合作和专业的态度与客户进行互动6.要求需求分析员和开发人员为需求和产品实现提供思路和备用方案要求需求分析员和开发人员为需求和产品实现提供思路和备用方案7.要求开发人员实现能让产品使用起来更容易、更有趣的特性要求开发人员实现能让产品使用起来更容易、更有趣的特性8.调整需求，便于重用已有的软件组件调整需求，便于重用已有的软件组件9.在提出需求变更时，获得对变

14、更的成本、影响及二者权衡关系的真实评估在提出需求变更时，获得对变更的成本、影响及二者权衡关系的真实评估10.获得满足功能和质量要求的系统，这些要求必须事先告知开发人员并征得其同意获得满足功能和质量要求的系统，这些要求必须事先告知开发人员并征得其同意软件客户有义务软件客户有义务1.为需求分析员和开发人员讲解业务并定义业务术语为需求分析员和开发人员讲解业务并定义业务术语2.提供需求，阐明需求，通过与开发人员的交互将需求充实完善提供需求，阐明需求，通过与开发人员的交互将需求充实完善3.对系统需求的描述必须详细、准确对系统需求的描述必须详细、准确4.需要时，及时对需求做出决断需要时，及时对需求做出决断

15、5.尊重开发人员对需求成本和可行性的评估尊重开发人员对需求成本和可行性的评估6.与开发人员协作，为功能需求、系统特性和用例设置优先级与开发人员协作，为功能需求、系统特性和用例设置优先级7.审阅需求文档，评估原型审阅需求文档，评估原型8.发现需要变更需求时，及时与开发人员沟通发现需要变更需求时，及时与开发人员沟通9.按照开发组织的变更控制过程提出需求变更按照开发组织的变更控制过程提出需求变更10.尊重需求分析员在需求工程中使用的过程尊重需求分析员在需求工程中使用的过程我们应该怎么办？我们应该怎么办？l对“需求”建立正确的认识；l客户和供应商一根绳子上的两个蚂蚱；l和客户一起建立起“共同的目标”；

16、l寻找并使用正确的、有效的需求捕获、描述（建模）、管理方法；l动态、持续地适应需求的变化；需求是什么？需求是什么？业务需求业务需求l业务需求是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。l背景描述：XX保险公司希望充分利用日益完善的移动通信技术，在原有的办公系统的基础上进行扩展，使得在外的业务人员能够及时地获得客户、业务相关的动态信息，与此同时，实现企业内部的即时通信。l业务需求/目标：通过该系统的实施，将人工保费续缴、投保手续办理两项业务运转周期缩短10以上，使企业内部沟通效率大幅改善，以帮助企业运转效率得以提高。业务目标示例业务目标示例某船厂商业管理系统

17、目标：A1.取代过时的系统A2.集成订单文档及数据库A3.使用经验数据进行报价A4.支持系统化的销售A5.快速捕获成本数据A6.加快发票的制作某医院管理系统目标：B1.降低IT成本人事部门：B2.实现一些任务的自动化B3.消除出错源B4.遵守最后期限B5.减少繁琐工作医院部门：B6.减少加班及工作量不足的情况B7.更快速的勤务规划B8.改进勤务表质量业务需求就是定义系统目标业务需求就是定义系统目标l现状：功能分解盛行的今天，常常会犯“盲人摸象”的错误，这使得需求太过脆弱，难以经受考验。l目标！目标！还是目标！-系统开发应目标驱动目标驱动！目标是团队唯一的行动纲领。l目标的定义不能够流于形式，应

18、该具有以下特征：业业务导向、可度量、合理、可行务导向、可度量、合理、可行。要注意目标太夸大会浪费资源，目标太缩小会影响士气。（教堂与小屋）l目标通常就是业务需求业务需求！业务需求就是定义系统目标业务需求就是定义系统目标l目标在哪里？业务需求是构建在“项目发起人”的脑子里的，也就是谁提出项目，谁就拥有对“业务需求”的最清晰的理解。l引出宏观的目标：思考企业运作中存在什么问题？这些问题主要是体现在哪些方面？这些问题对企业造成了什么影响？认为可以怎么解决？希望达到什么样的效果？l将大任务分解成为小目标，并且引导客户良好地定义，这也是我们形成“项目子目标描述”的关键基础。l衡量这些目标的合理性与可行性

19、。业务需求就是定义系统目标业务需求就是定义系统目标l形成一个不超过50字的项目目标，并且列出5-9个主要子目标，并且将其制作成一页文档，作为“项目的行动纲领”，还应该得到“项目发起人”的认可。l在此基础上，可以编写“项目的目标和范围文档”(或称项目综述，即POS，内容包括问题/机会、项目目标、项目目的、成功标准、假设/风险/障碍)，对于产品而言，我们还可以构建一个从市场角度分析的“愿景”文档。l该部分工作是处于“需求过程”的金字塔尖，多花费一些时间和精力是值得的，也是必要的。业务需求就是定义系统目标业务需求就是定义系统目标l有了清晰的目标之后，还应该对系统划定范围，最常用的方法是工作上下文范围

20、图（结构化分析方法）：用户需求用户需求l用户需求是指描述用户使用产品必须要完成什么任务，怎么完成的需求，通常是在问题定义的基础上进用户访谈、调查，对用户使用的场景进行整理，从而建立从用户角度的需求。l用户有不同类型：管理型、事务型 信息系统、人 决策层、使用层 常用者、偶用者l组织方法：用例、用户故事、特性l例子：对快到期的客户，系统将通过短信将续保信息发给该客户的代理人系统需求系统需求l解释一：系统需求是相关联的硬件、软件系统对待开发系统的相关需求。l解释二：从系统实现的角度描述的需求。l开发人员（设计及分析人员）在业务需求、用户需求的基础上生成的。功能需求功能需求l功能需求是需求的主体，是

21、需求的本质l功能需求定义了：系统必须完成的那些事，即为了向它的用户提供有用的功能，产品必须执行的动作 l零散（需求项）整理（特性、用例）l敏捷方法：用户故事质量属性质量属性l产品必须具备的属性或品质 l可靠性：成熟性、容错性、易恢复性l易使用性：易理解性、易学习性、易操作性l效率：时间特性、资源特性l可维护性：易分析性、易更改性、稳定性、易测试性l可移植性：适应性、易安装性、一致性、易替换性lMcCall体系：运行(正确性、可靠性、效率、完整性、使用性)、修正(维护性、测试性、灵活性)、转移(移植性、复用性、共运行性)设计约束设计约束l也称为限制条件、补充规约，这通常是对解决方案的一些约束说明

22、。l例如：必须采用国有自主知识版权的数据库系统l再如：必须运行在UNIX操作系统之下两个世界三种设计两个世界三种设计优秀的需求优秀的需求l完整性：完整描述即将交付使用的功能，发现缺少某项信息，可以采用TBD来标注l正确性：经过用户或用户信任的代理人审阅l可行性：在已知能力和约束条件中实现l必要性：每项需求记录的功能都应是用户真正需要的l有优先次序：提供了实现优先级l无歧义：对所有读者只有一种一致的解释l可验证性：可以设计测试方法来检查讨论讨论l前面的描述中，最大的感触是什么？Agenda需求的基本概念与原理需求的基本概念与原理需求工程需求工程需求定义最佳实践需求定义最佳实践需求捕获最佳实践需求

23、捕获最佳实践业务流程与规则分析业务流程与规则分析数据需求分析与建模数据需求分析与建模1）掌握需求的相关工作2）了解需求的相关人员需求错误的代价需求错误的代价需求：需求：1 1设计：设计：5 5编码：编码：1010测试：测试：20-5020-50运行与维护：运行与维护：200200需求开发与管理需求开发与管理需求开发活动需求开发活动需求开发需求开发 l需求开发可进一步细分为获取(Elicitation)、分析(analysis)、规格说明(specification)和确认(Validation)(Abran和Moore 2001)。l这些子学科涵盖了为软件和软件相关产品收集、评估和记录需求相关

24、的所有活动，包括：l确定产品将要面对的各类用户。l从各类用户的代表处收集需求。l了解用户的任务和目标，以及这些任务要实现的业务目标。l分析从用户处得到的信息，将用户的任务目标与功能需求、非功能需求、业务规则、解决方案建议及其他无关信息区分开来。l将顶层的需求分配到系统构架内定义好的软件组件中。l了解各质量属性的相对重要性。l协商需求的实现优先级。l将收集的用户需求表述为书面的需求规格说明和模型。l审阅需求文档，以确保在认识上与用户声明的需求相一致。应在开发小组接受需求之前解决所有分岐。45需求获取需求获取l应收集什么信息：问题域的描述 要求解决的问题列表（需求）用户对解系统的行为或结构施加的任

25、何约束l信息来源：客户（实际的和潜在的）任何原有解系统（已有系统）及其文档 原有系统用户/新系统的潜在用户 应用（问题）领域专家 定义了任何接口系统的特片和行为的文档 相关的技术标准和法规需求获取技术需求获取技术阅读背景资料阅读背景资料头脑风暴头脑风暴讨论分析讨论分析文档考古文档考古面谈（用户访谈）面谈（用户访谈）联合应用设计联合应用设计用户调查用户调查需求剥离需求剥离现场观摩现场观摩任务观察任务观察用例和场景用例和场景需求获取的误区需求获取的误区l缺乏计划性：随意、走过场，预先没计划l缺乏科学性：未从本质入手l捕获对象不明确，甚至造成岐义l过于迷信现有文档l过于迷信“听”到的东西需求分析需求

26、分析l所谓分析是指通过对问题域的研究，获得对该领域特性及存在于其中（需要解决）的问题特性的透彻理解并用文档说明l分析方法：结构化分析法、面向对象分析法、面向问题域分析法l任何分析法，均需描述以下几个方面:问题域的结构（子域，及子域间关系）问题域的数据 问题子域的固有属性及行为 问题域中的重要事件及现象 需求：应产生的效果需求分析需求分析何时进行何时进行l应该在“业务需求”充分理解，并且收集了最本质的“用户需求”之后就开始需求分析，但并不是等到需求捕获完全做完之后 l交替进行，先把握用户需求主要部分，然后在分析的基础上引入系统级的需求（系统的设计与实现角度），并且分析模型，成为开发人员之间、开发

27、人员与客户之间达成共识的一个平台l分析的基础上，就会发现更多的不明确项，更多待捕获的信息，这时就可以生成第二次的需求调研的计划、问题、素材 需求分析需求分析何时结束何时结束l需求捕获、分析与建模、规格说明书的编写、需求的验证这个需求开发的循环，是在整个软件开发生命周期中存在的 l每一次的循环，都将在需求开发的工作要点与份量上有所不同，它们应该遵循以下：从本质到边缘：本质、重要、次重要、一般、镶金 细化阶段是需求开发最密集的阶段 构建阶段需求开发逐渐减少需求分析需求分析内容与形式内容与形式l需求分析与建模不应该是孤立的行为，产生的结果也不一定非得是规范度很高的标准文档，而应该重在分析、重在方法、

28、重在交流、重在解决问题 l团队聚在一起，利用白板甚至是纸张，在充分的合作下进行分析与初步建模是成本最低、效率最高、实用性最强的方法 l对于这些活动所产生的结果，可以利用数码相机、扫描仪进行文档化，“直到你一定要用时，再写文档”l对于比较重要、核心的内容，再采用Rose、Together这样的工具进行文档化 编写规约编写规约l规格说明书是对需求分析结果的文档化过程l比较“正规”的开发组织都会重视这个活动，甚至可以说是“重视过度”，而且产生出来的文档经常是与实际的开发脱离，完成之后就束之高阁，再也不使用、不更新。这是一个需求崩溃的信号 l规格说明书的格式与所采用的开发过程、分析方法相关的，不同的方

29、法格式不同l定义统一的格式是一个很重要的工作l规约内容的严谨、正确、无岐义是很重要的需求验证需求验证l这个工作大多数组织都不够重视，导致这个工作直到交付系统时才真正被履行，这也就是为什么客户拿到系统后才提出许多这样那样的需求变更，甚至认为整个系统都不是他所需要的l提高需求质量的重要手段：需求评审 需求确认 通过原型来验证需求需求开发与需求管理的分界需求开发与需求管理的分界需求管理需求管理 l需求管理的任务是“与客户就软件项目的需求达成并保持一致”(Paulk et al.1995)。l需求管理包括下列活动：l定义需求基线(某一时刻，对特定版本中已达成一致的需求内容的描述)。l审查需求变更请求，

30、评估其可能产生的影响以决定是否批准。l以可控的方式将准的需求变更融入项目中。l保持项目计划与需求的同步。l估计需求变更的影响，在此基础上协商新的需求约定。l跟踪每项需求，找到与其对应的设计、源代码和测试用例(test case)。l在项目开发过程中，始终跟踪需求的状态和变更。56需求基线管理需求基线管理l频繁的需求变更会破坏开发的节奏，使整个项目开发的进度陷入混乱和失控的状态，而且会变成一个“救火队”式的工作，整天都在处理突发事件l将所有现在的、将来的需求进行优先级评估，然后分解成为不同的组，每次迭代都选择其中优先级最高的部分进行开发，然后在迭代完成之前，开发工作不响应变更，这些划入的需求项就

31、是需求基线的组成部分 需求基线管理需求基线管理操作思路操作思路l我们应该在分析的基础上，将需求整合成为用例或功能项，然后对其进行优先级、依赖性进行综合性评估l优先级判断：业务人员确定业务决定，技术人员确定技术决策；“满意度/不满意度”模型l依赖性是指对于某些功能，在实现上有必须的依赖关系，即当某些功能没有实现时，另外的功能无法开始，这就需要对其进行调整需求变更管理需求变更管理l需求变更是一定存在的，而需求变更管理并不是指逃避它，更不是说要避免它，它实际上是希望控制变更 l在基线内的需求不响应变更，为开发人员提供一个安静的工作时间状态 l专门的需求变更管理来对所有的需求变更进行响应，了解需求变更

32、的关键意图、新产生的工作量，从而良好地进行重新计划，以便能够有效地解决其对整个开发带来的麻烦 需求变更管理需求变更管理变更的流程变更的流程l提出变更：正式的方式提交变更是很重要的，合约式的沟通平台 l变更评估：合理性评估，进一步了解其变更的主要原因，认清其是否是因为沟通上的误会与不理解而造成的不必要的变更；工作量评估则是评估其对进度的影响；影响面分析则是评估该变更会对哪些部分工作产生影响，具体地说会对哪些人的工作产生影响l分级响应评估：不影响相关模块开发进度的，可直接响应；影响本模块开发进度但不影响项目总体进度的，可由项目经理协调后直接响应；影响项目进度的，则应该交与客户协商响应方式需求跟踪需

33、求跟踪l需求的跟踪是指对需求的完成情况、变更影响进行系统化的跟踪与处理l“需求是不是已经被实现？”、“需求的变化将需要修改哪些设计元素？会影响谁的工作？对已经完成的部分是否有影响？”需求管理的参与者需求管理的参与者需求分析师需求分析师l需求分析员是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者，是用户群体与软件开发团队间进行需求沟通的主要渠道l典型活动：定义业务需求、确定项目涉众和用户类别、获取需求、分析需求、为需求建模、编写需求规格说明、主持对需求的验证、引导对需求的优先级划分、管理需求l必备技能：倾听、交谈和提问的技巧，分析、协调、观察、写作、组织、建模、人际交往和创造能力需

34、求分析师需求分析师l必备知识：现代需求管理技术、各种软件开发生命周期、领域知识l需求分析员的来源：用户转为分析员（软件工程知识欠缺）、开发人员转为分析员（领域知识、沟通能力）、主题专家（易按自己的偏好来构建系统）需求过程需求过程需求过程需求过程Agenda需求的基本概念与原理需求的基本概念与原理需求工程需求工程需求定义最佳实践需求定义最佳实践需求捕获最佳实践需求捕获最佳实践业务流程与规则分析业务流程与规则分析数据需求分析与建模数据需求分析与建模对问题进行了正确的定义意味着成功解决了问题的一半讨论讨论l你认为需求定义的目标是什么？l通常需求定义在什么阶段进行？l其主要的产物是什么？信息系统立项前

35、的分析方法信息系统立项前的分析方法lGPOA方法：GoalProblemOptionAnswer信息系统立项前的分析方法信息系统立项前的分析方法lG（目标）：要确定需要开发某个信息系统之前，应该分析其应该达到的目标：业务性、可度量lP（问题）：要达到该目标所需解决的问题！lO（选项）：针对这些问题可选的解决方案lA（答案）：针对各种Option进行分析、评估，最终确定答案。信息系统立项可行性分析信息系统立项可行性分析l确定目标：信息系统实现前，信息系统实现后l提出解决方案：分析P，给出O，得出Al可行性分析：效益分析：经济可行性，投资回报 社会可行性 技术可行性信息系统立项时的常见误区信息系统

36、立项时的常见误区l目标：含混不清，过为宏观 Solution:基于业务需求思考l解决方案：思路过于受限 Solutions:只想What，别想How 了解、理解IT技术l期望值：脱离现实l发起人、用户、使用者想法不一致 框定问题的技巧框定问题的技巧l问题的定义是需求工作的第一步，也是最重要的一步。l问题是否能够解决，通常与是否能够更好、更准确地框定问题相关。l例如，经典的马的遍历问题：寻找一系列的移动步骤，使马走完每个方块，而落入任何一个方块一次：框定问题的技巧框定问题的技巧框定问题的技巧框定问题的技巧l软件需求第一和可能最重要的步骤是框定问题把问题的特定部分，以及部分间特定的关系，放入一个特

37、定的形式中。问题框定方法应使问题的细节适合一个简单连贯的框架l同时，这也表现出，深入地理解问题域的知识，正确地抓住其本质特性，是十分重要的。l（你的灯还亮着吗？）框定问题的技巧框定问题的技巧l问题：日内瓦湖上的山脉中建成了一条很长的汽车隧道，为了防止停电时发生灾难，必须提醒司机进入隧道之前把车灯打开。l解决方案一：“警告！前有隧道请打开车头灯警告！前有隧道请打开车头灯”l新问题：隧道出口风景很美，返回时发现汽车没电忘了关车头灯！l解决方案二：出口处立标牌出口处立标牌“关掉车灯关掉车灯”l新问题：夜行车也会关掉车灯？l解决方案三：建充电站建充电站l新问题：维护开支大，充电站也会出故障框定问题的技

38、巧框定问题的技巧l解决方案四：授权私人经营充电站授权私人经营充电站l新问题：风景区商业化，政府与游客均不接受l解决方案五：在隧道尽头，树立新标牌 如果是白天，并且车灯开着，请熄灭车灯；如果是白天，并且车灯开着，请熄灭车灯；如果天色已晚，并且车灯没开，请打开车灯；如果天色已晚，并且车灯没开，请打开车灯；如果是白天，并且车灯没打，就别打开它；如果是白天，并且车灯没打，就别打开它；如果天色已晚，并且车灯开着，请别关掉它。如果天色已晚，并且车灯开着，请别关掉它。l新问题：谁能在行驶时读完？！l终极解决方案：你的灯亮着吗？你的灯亮着吗？问题分析的五个步骤问题分析的五个步骤l问题分析：理解真实世界中的问题

39、和用户的需求并提出满足这些多方面要的解决方案的过程l在问题定义上达成共识l理解根本原因问题背后的问题l确定风险承担人和用户l定义解决方案系统的界限l确定加在解决方案上的约束在问题定义上达成共识在问题定义上达成共识l把问题写下来，看每个人是否都同意l采用标准化格式：问题：描述问题 影响：确定受问题影响的风险承担人 结果：确定问题对风险承担人和商业活动的影响 成功的解决方案：指出解决方案并列出主要优点理解原因后对问题的陈述理解原因后对问题的陈述l问题：不准确的订单l影响：订单操作者、客户、生产者、销售者及客服l结果：增加废品、额外处理成本、客户不满及收益降低l成功的解决方法：增加了输入点订单的准确

40、性 增加了销售数据的报告以便进行管理 获得更好的效率理解原因后对问题的陈述理解原因后对问题的陈述l问题：随时提供大学体育赛事的最新报道 l影响：移动办公的人群 l结果：他们不可能花很多时间来搜索他们感兴趣的新闻，因此无法随时了解到有关他们母校的赛事（或者他们感兴趣的其他大学的体育赛事）。l成功的解决方法：当发生他们感兴趣的新闻时，向他们发出通知，并提供一个地点来为他们提供所请求的新闻。理解根本原因理解根本原因问题背后的问题问题背后的问题lTQM的鱼骨图l帕雷托图确定风险承担人和用户确定风险承担人和用户l系统的用户是谁？l系统的客户是谁？l还有哪些人会受系统输出的影响？l系统完成并投入使用后，有

41、谁会对它进行评估？l还有没有其他系统内部或外部用户，他们的需要有没有必要被考虑到？l系统将来由谁维护？l还有其他人吗？定义解决方案系统的界限定义解决方案系统的界限l谁会对系统提供信息？谁会在系统中使用信息？谁会从系统中删除信息？l谁将操作该系统？l谁是系统的维护者？l系统将会在哪儿被使用？l系统从哪儿得到信息？l哪些外部系统要和系统进行交互？定义解决方案系统的界限定义解决方案系统的界限不好！大部分工作都留给操作员了常见划分，但可以更好订单接收自动化顾客缺货前提醒确定加在解决方案上的约束确定加在解决方案上的约束l经济约束：预算？l行政约束：存在许可问题？潜在内外部政问题？部门间问题？l技术约束：

42、技术选择有何限制？限制在已有平台或技术上？禁止使用新技术？需要购买软件包？l系统约束：建立在现有系统上？需要维护与原系统的兼容性？必须支付什么操作系统？l环境约束：合法吗？安全性要求？其他标准限制？l进度及资源：进度要求？已有资源？外部劳动力可用否？有无扩展资源？确定加在解决方案上的约束确定加在解决方案上的约束l操作性：销售订单数据必须在数据库中备份一年，因为数据丢失风险太大，需并行运行至少一年的数据l系统及操作系统：应用在服务器上占用不超过200M，因为服务器上存储空间有限l设备预算：必须在已有服务器和主 机上开发l人员预算：固定的人力资源，没有外部资源l技术要求：应用新的面向对象的方法项目

43、定义项目定义业务需求业务需求l产品/项目的目的：对业务目标的简短、可度量的描述l客户：为谁构建？顾客：谁会购买？l风险承担者：哪些人在产品中拥有既得利益？l用户：谁将操作它？他们的能力如何？l限制条件：必须采用某设计方案？时间？经费？l名称：该项目使用哪些术语？l相关事实和假定：每个人都需要知道什么？l工作的范围：什么是产品和项目的边界？l估算的费用：需要花费多少工作量或资金l风险：面临的主要风险项目定义项目定义目标的六要素目标的六要素l目标：精确预报道路结冰时间并分派除冰卡车l业务优势：通过预报道路结冰情况来减少道路事故l度量：因结冰而发生的事故数年将低于冬季发生的事故总数的15%l合理性：

44、消除因结冰而发生的事故而减少的损失，与构建该系统所花费的成本和工作量相比，是否有价值？l可行性：及时地除冰能否减少事故的发生？会降到总数的15%以下吗？l可达成性：该目标能达到吗？项目定义项目定义风险承担人与用户风险承担人与用户l用户：与主题相关的经验、技术上的经验、智力能力、对工作的态度、对技术的态度、受教育程度、语言技能、年龄、性别l风险承担者：用户、客户、顾客、管理者、业务主题相关者、开发人员、检查人员、市场力量、法律方面、反对者、专业团体、公众意见、政府、特殊利益团队、技术专家、文化利益、相邻系统l（Stakeholder解析）项目定义文档项目定义文档前景文档前景文档l业务需求 背景：

45、新产品的来由与背景 业务机遇 业务目标与成功标准 客户与市场需求 业务风险l解决方案的前景 前景说明(目标客户、需求与机会、竞争对手与优势)主要特性 假设与依赖项目定义文档项目定义文档前景文档前景文档l范围与限制 第一个版本的范围 各后续版本的范围 限制与排除l业务背景 涉众简介 项目优先级 操作环境需求心理学需求心理学常见现象常见现象l言过其实心理：说的流程是一种理想化流程，与实际情况严重不符l越俎代疱心理：对非自己处理的流程津津热道，根据自己的理解、想像进行肯定的描述l非正事心理：一直忙于工作，无瑕配合需求调研l抗拒心理：新系统对其利益有损，故意不配合l推卸责任心理：装不知，说没需求需求变

46、化的预期需求变化的预期l流程变化：流程顺序变化，流程细节变化，流程负责人变化，流程输入变化，流程输出变化。l数据变化：数据格式变化、数据规则变化、数据输出变化、数据项变化l业务规则：规则增加、规则减少、规则变化l系统表现形式变化：界面、风格、输入形式、展现方式、访问方法、网络环境l目标变化Agenda需求的基本概念与原理需求的基本概念与原理需求工程需求工程需求定义最佳实践需求定义最佳实践需求捕获最佳实践需求捕获最佳实践业务流程与规则分析业务流程与规则分析数据需求分析与建模数据需求分析与建模需求捕获是一个探索的过程是一个有计划、科学性的过程讨论讨论l平时需求捕获怎么做？l需求捕获有哪些方法？l主

47、要的优缺点是什么？l在需求捕获过程中遇到的主要障碍有哪些？需求捕获的主要障碍需求捕获的主要障碍l大多数情况下，系统相关的人员无法陈述自己的需要l许多用户难以解释所执行的任务，更难解释为什么执行这些任务l相关人员经常指定解决方案而不是需求l相关人员也难以构想出新的工作方法，或者想像出使用提供的方法执行熟悉的任务所能够得到的结果l不同的相关人员可能持有相互矛盾的观点l相关人员经常出于抵制变更而拒绝新系统l需求可能过多过度的需求l需求随着时间而变化需求捕获的各方职责需求捕获的各方职责l由需求分析师策划，由需求分析师、用户和其他风险承担者积极合作完成。l用户、顾客和客户：有责任向需求分析师提供他们的工

48、作知识l需求分析师：理解用户所说的关于工作的事情，并将其解释成产品的需求规格说明 观察和学习该项工作，从用户角度来理解它 用户对某项工作的描述必须作为事实来对待，要发现工作的本质，而非表象 发明完成该工作更好的方法 以需求规格说明书和分析模型的方式记录用户在需求捕获过程中的角色用户在需求捕获过程中的角色l作为设计组、专题讨论会的成员，参与设计用户界面l作为知识来源，提供任务、商业过程的当前执行情况l参与集策讨论会，提供构想、确定问题l作为测试用户，在验收时测试系统检查能否正常工作l作为审查者评估用户界面l进行可用性测度，尝试使用新的用户界面执行任务l作为项目管理委员会成员用户的各种需求用户的各

49、种需求l意识到的需求：是指那些用户最先想到的需求，常常表明用户希望改进的一些事情l无意识的需求：是指那些用户没有言明的事情，因为用户对它们知道得太多，以致于他们假定其他任何人都具备同样的知识l未梦想过的需求：是指那些一旦用户认识到它们可能就会要求的事情系统化地组织需求捕获系统化地组织需求捕获l术语表、域建模、领域培训这些都是因地制宜的业务建模的常见工具。（Wiki）l与业务流程相关的系统，最重要的是：置身于流程之中，分析信息、工作流。l从“组织结构与岗位设置图”所体现的管理层次与线条建立全局了解；-参与者的来源；l针对业务流程，绘制出跨部门职能流程图，以帮助开发人员对客户方的业务流程建立宏观、

50、清晰的认识，以便更加有的放矢地进行进一步的需求捕获工作。跨部门职责流程图跨部门职责流程图跨部门职责流程图跨部门职责流程图系统化地组织需求捕获系统化地组织需求捕获l应该搜集什么信息？应该搜集什么信息？细化地研究流程图，看看是否已经对每个环节、每个步骤都清楚地认识了。我们应该根据自己的理解首先对每个流程的工作进行定义，写出事件流，并且标识出疑问点，这些都将使我们明白“应该收集什么信息”。l从哪搜集这些信息？从哪搜集这些信息？流程涉及到什么部门、岗位，答案就应该从谁身上找。l用什么机制来搜集？用什么机制来搜集？需求捕获技术有多种，重点在于因地制宜地使用不同的机制主要需求捕获技术比较主要需求捕获技术比

51、较当前工作当前问题目标及关键问题未来系统构想切实的可能性结果及风险认可冲突决议最终需求优先级完整性相关人员分析BACCBBC用户访谈AABCC现场观摩ABCB任务示范AABCB文档考古ABCB用户调查BBCC集策讨论会A重点问题讨论会AAABCCA域专题讨论会AAABBBBBBB设计专题讨论会CABCBCA主要需求捕获技术比较主要需求捕获技术比较当前工作当前问题目标及关键问题未来系统构想切实的可能性结果及风险认可冲突决议最终需求优先级完整性原型设计CABBAC小规模试验CAAABBB研究类似公司CBAAAB询问供应商CCBABB协商CBCCCAABA风险分析BBAC成本/效益分析BBCCACA

52、目标-域分析BBBCABCBBA域-需求分析CBCABB用户访谈用户访谈l用户访谈用户访谈：最基本、最常见的技术l利：直接有效、形式灵活、交流深入，应该做为主要的需求捕获技术（宽带通信、固有灵活性、各类信息）l弊：占用时间长（特别当客户忙时更显示出其不足）、面窄而容易造成信息的片面性。l要点：首先要有准备：通常包括说明对流程的理解，并征得客户的意见；预先根据流程中的不明确点设计要询问的问题，并将客户的反馈记录下来；应留有一些即兴的空间，根据实际情况应变，以确保信息完善。第二是要有计划性：计划好时间、计划好人员、计划好策略。用户访谈：特点用户访谈：特点l最传统的方法，单独使用并不有效，通常别期望

53、用户知道并能够说出他们的需求l应先草拟一份问卷，向要访谈的用户发出一份涉及访谈主题和时间安排的材料l在访谈的过程中，及时用草图绘制模型（DFD、用例、思维图），从而得以及时反馈l应以业务事件为谈话的中心，l问问问题，听听取回答，然后反馈反馈理解用户访谈：准备工作用户访谈：准备工作l围绕目标制订一个计划，包括一组按逻辑方式分组和排序的问题l在计划内应有时间在结束时检查是否已涵盖所有问题，并理解对所有问题的答复l不要超过1小时，否则应安排下一次面谈l地点选择：适当的不受干扰和避免打扰l记录：自己做笔记（分神）、专门一同事做笔记（成本高）、录音（失去身体语言）/录像（难操作）自己做笔记+录音用户访谈

54、：通用问卷用户访谈：通用问卷l建立客户或用户情况表 姓名、职位等基本信息 你的主要职责是什么？你们的主要输出是什么？为谁做的？如何测试成功?什么问题阻挠你们的成功?如果有，什么使你的工作更容易或更困难用户访谈：通用问卷用户访谈：通用问卷l评估问题 你对哪种问题缺乏好的解决方案？它们是什么？（提示：不断问“还有吗？”）对每个问题，问：为什么存在这个问题？现在你怎么解决它？你打算怎么解决它？用户访谈：通用问卷用户访谈：通用问卷l理解用户环境 谁是用户？他们的教育背景如何？他们的计算机背景如何？用户经历过这种类型的应用吗?使用的是哪一种平台？计划将来的平台是什么？有没有用其他和该应用有关的应用？如果

55、有简单介绍 对产品可用性的预期是什么?你需要什么样的用户帮助（在线文档、纸介质？）用户访谈：通用问卷用户访谈：通用问卷l简要说明理解情况 你刚才告诉我（用自己的话列出客户所述问题）这是否足以表达你认为现在存在的问题？如果还有，那是什么问题？l分析人员对客户问题的输入(有效或无效的假设)，如果有，问题与什么有关？对于每个建议，提问:这是一个实际的问题吗？产生的原因是什么？你是怎么解决这个问题的？希望怎么解决？和你提到的其他问题相比，这些问题 的位置如何？用户访谈：通用问卷用户访谈：通用问卷l评估你的解决(总结你建议的解决方案的主要功能)如果你能够对于这些的重要性，你是如何排序的？l评估机会 在你

56、的单位中，谁需要这样的应用？使用这种应用的用户有多少?如何评价一个成功的解决方案?用户访谈：通用问卷用户访谈：通用问卷l评估可靠性、性能及支持的需要 你对可靠性的预期是什么？你对性能的预期是什么？是你还是其他人来支持该系统？你对支持还有特别的要求吗？维护及服务如何?安全需求是什么？安装和配置需求是什么？有什么特殊的许可需求吗？用户访谈：通用问卷用户访谈：通用问卷l其他需求 有必须支持的法律、法规、环境需求或标准吗？你还能想到其他我们应该知道的需求吗?l总结性提问 我还有其他问题应该问你吗？如果我还问你其他问题的话，可以打电话给你吗？你愿意参加需求审阅吗？l分析人员总结：面谈后，趁你记得时，总结

57、出用户/客户确认的三条最高优先级的需求或问题用户访谈：操作法用户访谈：操作法l避免类似以下暗示：我的时间比你宝贵，我不知道我在做什么，你不知道你在讲什么l用简单的语言清楚地表达问题，采用对方的术语和行话l不要遗漏任何事情l能够找到和探究异常现角，例如对未预料问题的反应l不要搞错基本信息流要求的方向用户访谈：询问的问题用户访谈：询问的问题l问题类型：待解决的问题、开发解决方案的过程、需求获取本身l需求获取本身的问题：我的问题看起来相关吗？你的回答正式吗？你的回答正式吗？你是回答这些问题的最佳人选吗？你是回答这些问题的最佳人选吗？我问了太多的问题吗？还有其他什么我该问你的？你想问我什么？我还应该见

58、其他什么人？关于这个项目有什么人我们不需要？用户访谈：主要困难用户访谈：主要困难l缺乏对所需要的人的访问（知道最多的人最忙）l在面谈时记录信息很困难l被访谈人会试图说他们认为你想要听的话l访谈人用诱导性问题提问l束缚关键职员的有关费用l由不同领域知识和行话引起的交流困难l隐蔽的动机和组织政策产生错误信息用户调查：概述用户调查：概述l用户调查：用户调查：调查面最广的技术l利：面广，能够获得更多的人的反馈。这点是对用户访谈技术不足之处的最好补充。l弊：不够深入，容易形而上学。而这点是正是用户访谈技术所能够解决的。l要点：结合用户访谈技术使用，具体来说：先设计问题，制作成为用户调查表，下发填写完后，

59、进行仔细的分组、整理、分析，以获得基础信息，然后再针对这个结果进行小范围的用户访谈，作为补充。用户调查：主要用途用户调查：主要用途l搜索某项假设的统计依据搜索某项假设的统计依据：设计一些封闭的问题，例如“从现有系统中取得客户统计资料的难易程度：非常困难、相当困难、容易、非常容易”l搜索意见、建议搜索意见、建议：询问与用户访谈类似的开放性问题，例如“日常工作中的三个最大问题是什么？”，“你对能够更好地支持日常工作的IT系统有什么建议”。-误解你的问题，你误解他的回答用户调查：主要困难用户调查：主要困难l相关的问题不能事先决定l问题背后的假设对答案会造成偏颇 例如：这功能符合你的期望吗？假设：你有

60、期望，所以这是一个有意义的提问l难以探索一些新的领域，也没有探索新的需要被探索的领域的交互l难以继续用户的模糊响应用户调查示例现场观摩：概述现场观摩：概述l现场观摩：现场观摩：最生动的技术l利：百闻不如一见，能够对需求与业务流程建立直观的认识。l弊：消耗时间长，而且由于“被观摩”的微妙心理变化，会使得“观摩”失真。l适用性：要对于复杂流程的更加深入的理解时。l要点：悄悄地进行，明确要强化理解的具体流程环节。现场观摩：常用变体现场观摩：常用变体l任务示范：任务示范：要求用户示范如何执行特定的任务l利：可用于发现异常的、关键性的任务l弊：“示范”失真、耗时l做学徒：做学徒：和用户坐在一起，通过观察

61、、问问题、并在用户指导下完成一些工作来学习l适用性：用户无法详细解释清楚他们在做什么时l“人们正在做一件事时，最能解释他们在做什么，为什么要这么做”l需求分析员可以通过学徒关系试验他的需求和设计思想文档考古：概述文档考古：概述l文档考古：文档考古：最贴近实现的技术l利：能详细、直观地对数据流细节进行了解与分析。l弊：易陷入文山书海之中不可自拔，甚至常引起误导。l要点：应该尽量让客户提供写有真实数据的文档。l特点：从旧的工作材料中挖掘新的需求l检查收集的文档，从中找出名词，或“东西”，包括列标题、命名的表格区域l涉及内容：文档、打印输出、清单、手册、屏幕等文档考古：常用思考点文档考古：常用思考点

62、l此物的目的是什么？怎么用它？为什么用它？用它做什么？系统都利用它来做些什么？l哪些业务事件用到或引用了此物？此物会有一个值吗？是数字、代码、数量？如果是这样的话，它属于哪些东西的组成体？l此物的用途是什么？l文档中是否包含了一组重复的事物？如果是这样的话，这些事物的集合称为什么？文档考古：常用思考点文档考古：常用思考点l我能找到事物之间的联系吗？l什么过程建立了它们之间的联系？l每件事物附加的规则是什么？换句话说，哪部分业务策略涉及该事物？l什么过程确保了这些规则会被遵守？l什么文档给用户最多问题？文档考古：优缺点文档考古：优缺点l优：获取信息相对比较直接，获得系统所有输入、输出及内部文档（

63、但不应假定已获得全部描述）；有助于数据模型分析。l缺：文档说明的系统与实际系统可能是不匹配的；文档考古的传统分析方式（如开发文档流图）可能导致产生现有系统的结构模型，从而带入新系统联合开发：概述联合开发：概述l联合开发：联合开发：最理想的技术l利：客户、开发人员直接的头脑风暴，是击破需求盲点的关键手段。l弊：成本高，如果缺乏控制会变成一次闲扯大会。l要点：需要有一个经验丰富、能够把控大局的主持人。联合开发：优点联合开发：优点l协助建立一支高效的团队，围绕一个目的：项目成功l所有风险承担人都畅所欲言，没人被落下l正如应用项目所必须做的，它促进风险承担人和开发团队之间达成共识l它能够揭露和解决那些

64、妨碍项目上成功的行政问题l能够产生一个在特征级别上的初步系统定义联合开发：准备工作联合开发：准备工作l推销概念：充分的准备是联合开发的关键，推销联合开发（需求专题讨论会）的好处l确保真正的风险承担人参与l后勤保障l热身材料：在开会前散发资料 项目专有信息：需求文件草案、已排序的特性 摆脱束缚思想的：提供创新方法、自由讨论规则 2天1周内散发，太早会使人忘记！联合开发：准备工作联合开发：准备工作 备忘录备忘录收件人：收件人：XXX项目的风险承担人项目的风险承担人主主 题：即将召开的需求专题讨论会题：即将召开的需求专题讨论会 我是我是XX产品（项目）的管理者。这个项目已经（或即将）于产品（项目）的

65、管理者。这个项目已经（或即将）于 开始并截止于开始并截止于 完成。完成。（我们了解它，我们是认真的，我们想要按时完成它）正如大多数的项目一样，获得关于应用项目的新特征的共识并定义一个最初的基本系统来正如大多数的项目一样，获得关于应用项目的新特征的共识并定义一个最初的基本系统来满足不同风险承担人的需要是十分困难的。满足不同风险承担人的需要是十分困难的。（它甚至比在这个组达成任何其他共识更，因此我们将尝试一些不同的方法）为了使这个过程更加容易，我们将召开一次关于为了使这个过程更加容易，我们将召开一次关于 的需求专题讨论会。的需求专题讨论会。专题讨论会的目标是：为产品的下一个基线版本确定新特性。为了

66、做到这些，听取每一个专题讨论会的目标是：为产品的下一个基线版本确定新特性。为了做到这些，听取每一个风险承担人的意见就极为重要。专题讨论会将由风险承担人的意见就极为重要。专题讨论会将由 来主持，他是一位经验丰富的需求管理联来主持，他是一位经验丰富的需求管理联络员。络员。（作为风险承担人，我们可能也有偏见，从外面聘请主持人可以使其更公平）专题讨论会将很快得出结果，并在第二天将结果分发给开发部。我们热忱地邀请您参加专专题讨论会将很快得出结果，并在第二天将结果分发给开发部。我们热忱地邀请您参加专题讨论会并提出代表你的（团队、部门、用户）需求的意见。如果您无法参加，我们热切地希题讨论会并提出代表你的（团队、部门、用户）需求的意见。如果您无法参加，我们热切地希望你能够授权一名代表您的需求的成员参加。望你能够授权一名代表您的需求的成员参加。（会后第一天我们将开始工作；如果你希望对项目提出什么意见，请到这里来，或授权一名代表来。换句话说，要么现在说，要么永远别说。）备忘录中有一个关于当前产品期望特征的简短说明，以及其他关于专题讨论会和自由讨论备忘录中有一个关于当前产品期望特征的简短说明，以及其他关于专