需求捕获最佳实践讲述
针对业务流程，绘制出跨部门职能流程图，以帮助开 发人员对客户方的业务流程建立宏观、清晰的认识， 以便更加有的放矢地进行进一步的需求捕获工作。
系统化地组织需求捕获
应该搜集什么信息？细化地研究流程图，看看是否已 经对每个环节、每个步骤都清楚地认识了。我们应该 根据自己的理解首先对每个流程的工作进行定义，写 出事件流，并且标识出疑问点，这些都将使我们明白 “应该收集什么信息”。
讨论
平时需求捕获怎么做？ 需求捕获有哪些方法？ 主要的优缺点是什么？ 在需求捕获过程中遇到的主要障碍有哪些？
需求捕获的主要障碍
大多数情况下，系统相关的人员无法陈述自己的需要 许多用户难以解释所执行的任务，更难解释为什么执
行这些任务 相关人员经常指定解决方案而不是需求 相关人员也难以构想出新的工作方法，或者想像出使
用户访谈：通用问卷
简要说明理解情况 > 你刚才告诉我…（用自己的话列出客户所述问题） > 这是否足以表达你认为现在存在的问题？ > 如果还有，那是什么问题？
分析人员对客户问题的输入 (有效或无效的假设)，如果有，问题与什么有关？ 对于每个建议，提问: > 这是一个实际的问题吗？产生的原因是什么？ > 你是怎么解决这个问题的？希望怎么解决？ > 和你提到的其他问题相比，这些问题 的位置如何？
不要超过1小时，否则应安排下一次面谈 地点选择：适当的不受干扰和避免打扰 记录：自己做笔记（分神）、专门一同事做笔记（成
本高）、录音 （失去身体语言）/录像（难操作） 自己做笔记+录音
用户访谈：通用问卷
建立客户或用户情况表 > 姓名、职位等基本信息 > 你的主要职责是什么？ > 你们的主要输出是什么？ > 为谁做的？ > 如何测试成功? > 什么问题阻挠你们的成功? > 如果有，什么使你的工作更容易或更困难
面窄而容易造成信息的片面性。 要点：首先要有准备：通常包括说明对流程的理解，
并征得客户的意见；预先根据流程中的不明确点设计 要询问的问题，并将客户的反馈记录下来；应留有一 些即兴的空间，根据实际情况应变，以确保信息完善。 第二是要有计划性：计划好时间、计划好人员、计划 好策略。
用户访谈：特点
最传统的方法，单独使用并不有效，通常别期望用户 知道并能够说出他们的需求
应先草拟一份问卷，向要访谈的用户发出一份涉及访 谈主题和时间安排的材料
在访谈的过程中，及时用草图绘制模型（DFD、用例、 思维图），从而得以及时反馈
应以业务事件为谈话的中心， 问问题，听取回答，然后反馈理解
用户访谈：准备工作
围绕目标制订一个计划，包括一组按逻辑方式分组和 排序的问题
在计划内应有时间在结束时检查是否已涵盖所有问题， 并理解对所有问题的答复
需求分析师：理解用户所说的关于工作的事情，并将 其解释成产品的需求规格说明 > 观察和学习该项工作，从用户角度来理解它 > 用户对某项工作的描述必须作为事实来对待，要发 现工作的本质，而非表象 > 发明完成该工作更好的方法 > 以需求规格说明书和分析模型的方式记录
用户在需求捕获过程中的角色
作为设计组、专题讨论会的成员，参与设计用户界面 作为知识来源，提供任务、商业过程的当前执行情况 参与集策讨论会，提供构想、确定问题 作为测试用户，在验收时测试系统检查能否正常工作 作为审查者评估用户界面 进行可用性测度，尝试使用新的用户界面执行任务 作为项目管理委员会成员
越俎代疱心理：对非自己处理的流程津津热道，根据 自己的理解、想像进行肯定的描述
非正事心理：一直忙于工作，无瑕配合需求调研 抗拒心理：新系统对其利益有损，故意不配合 推卸责任心理：装不知，说没需求
需求变化的预期
流程变化：流程顺序变化，流程细节变化，流程负责 人变化，流程输入变化，流程输出变化。
用户访谈：通用问卷
评估问题 > 你对哪种问题缺乏好的解决方案？ > 它们是什么？（提示：不断问“还有吗？”） > 对每个问题，问： > 为什么存在这个问题？ > 现在你怎么解决它？ > 你打算怎么解决它？
用户访谈：通Βιβλιοθήκη 问卷理解用户环境 > 谁是用户？ > 他们的教育背景如何？ > 他们的计算机背景如何？ > 用户经历过这种类型的应用吗? > 使用的是哪一种平台？计划将来的平台是什么？ > 有没有用其他和该应用有关的应用？如果有简单介 绍 > 对产品可用性的预期是什么? > 你需要什么样的用户帮助（在线文档、纸介质？）
数据变化：数据格式变化、数据规则变化、数据输出 变化、数据项变化
业务规则：规则增加、规则减少、规则变化 系统表现形式变化：界面、风格、输入形式、
展现方式、访问方法、网络环境 目标变化
系统化地组织需求捕获
术语表、域建模、领域培训—这些都是因地制宜的业 务建模的常见工具。（Wiki）
与业务流程相关的系统，最重要的是：置身于流程之 中，分析信息、工作流。
用提供的方法执行熟悉的任务所能够得到的结果 不同的相关人员可能持有相互矛盾的观点 相关人员经常出于抵制变更而拒绝新系统 需求可能过多—过度的需求 需求随着时间而变化
需求捕获的各方职责
由需求分析师策划，由需求分析师、用户和其他风险 承担者积极合作完成。
用户、顾客和客户：有责任向需求分析师提供他们的 工作知识
用户的各种需求
意识到的需求：是指那些用户最先想到的需求， 常常表明用户希望改进的一些事情
无意识的需求：是指那些用户没有言明的事情， 因为用户对它们知道得太多，以致于他们假定 其他任何人都具备同样的知识
未梦想过的需求：是指那些一旦用户认识到它 们可能就会要求的事情
需求心理学—常见现象
言过其实心理：说的流程是一种理想化流程，与实际 情况严重不符
从哪搜集这些信息？流程涉及到什么部门、岗位，答 案就应该从谁身上找。（闲聊惹的祸）
用什么机制来搜集？需求捕获技术有多种，重点在于 因地制宜地使用不同的机制……
用户访谈
用户访谈：最基本、最常见的技术 利：直接有效、形式灵活、交流深入，应该做为主要
的需求捕获技术（宽带通信、固有灵活性、各类信息） 弊：占用时间长（特别当客户忙时更显示出其不足）、
软件需求最佳实践
软件需求最佳实践软件需求是软件开发过程中第一步，也是最主要的步骤。
在这一步中，软件开发团队和客户之间建立起了信任关系，以确保将设想的软件变成现实的最终产品。
此外，它的正确性和可行性也对软件开发项目的成功至关重要。
软件需求分析（SRA）会帮助团队明确客户的最终需求，为软件开发团队提供设计和开发良好的软件的基础。
它还可以使客户和软件开发团队之间的沟通更加高效，以防止客户在软件开发项目中发生不必要的延误和错误。
SRA本质上是对软件需求的综合识别、定义、确定、验证、分析、调整，以确保满足客户需求的前提下，找出最有利的、最合适的、最实用的软件解决方案。
软件需求分析的最佳实践涉及三个基本步骤：1）分析和获取，2）定义和模型，以及3）实施和迭代。
首先，团队应该分析客户的业务流程，获取客户对最终软件的期望，以及客户如何优化他们的业务流程。
接下来，团队应该形成具有清晰定义和文档的概念模型，以便他们能够以有效的方式开发和持续改进软件。
最后，团队应该实施软件开发项目，并随着时间的推移，对软件需求进行迭代改进。
软件需求最佳实践的关键要素包括：在沟通中心置客户为主，同意所谈及的需求是可行的，确定可用资源，明确项目时间表，确立成功指标，建立文档，控制风险，合理弥补，以及在开发周期中提供有效的沟通技巧。
此外，软件开发团队也需要利用技术，比如Agile，Scrum，敏捷软件开发，快速原型设计等方法。
这些方法可以帮助团队有效地开发和实施软件，使软件开发团队能够更好地实现客户的需求。
软件需求分析最佳实践是实施软件项目的关键，并为软件项目提供了一个巩固的基础。
客户和开发团队都需要紧密地协同工作，共同推动软件项目的成功实施，并为获得更大的成功做好准备。
此外，在实施软件项目的过程中，客户和开发团队都需要注意需求的实时变化，以确保软件项目能够及时和有效地交付。
因此，一个健全的软件需求最佳实践是软件项目成功实施的关键。
软件需求工程的最佳实践和经验分享
软件需求工程的最佳实践和经验分享本文介绍了软件需求工程的最佳实践和经验分享。
软件需求工程是软件工程中非常重要的一环，它的质量将直接影响到最终软件的质量和客户的满意度。
为了更好地进行软件需求工程，本文总结了以下三个最佳实践和经验分享，包括需求管理、需求分析和需求建模。
一、需求管理需求管理是软件需求工程的第一步，它是所有后续工作的基础。
需求管理需要从以下几个方面展开：1.需求收集和分析：需求收集和分析是软件需求工程的重要环节，它同时也是需求管理的起点。
在这个过程中，我们需要深入地理解客户的需求，收集和整理需求，将它们转化为具体的需求清单，并且分析这些需求之间的关系、是否冲突等情况。
2.需求有效性评估：需求收集和分析完成后需要进行需求有效性评估。
通过对需求有效性的评估，可以保证需求的准确性、完整性和可行性，并且确定哪些需求是关键的、高优先级的，这些需求需要优先实现。
3.需求跟踪：在软件开发过程中，需求不断地变化和更新，而需求跟踪可以帮助我们及时地更新需求清单和相关的规范，同时也可以记载变化原因、发现漏洞并进行修改等。
二、需求分析需求分析是软件需求工程的核心环节，也是分析客户需求的一项重要工作，需要注意以下几个方面：1.需求分解和优化：对于复杂的需求，需要将其分解成多个简单的需求，将其逐一实现；对于需求冲突和不确定性，需要进行优化来确保达到最优解。
2.需求交互分析：在与客户沟通时需要及时地了解客户需求及其交互，采用适当的方法分析需求集合，加载需求选择器等技术，帮助在交互设计和协调上做出准确的决定。
3.需求验证：需求分析过程常常存在偏差和误解，以及难以预测现象的发生，因此我们需要创建合适的模型以进行需求验证，并重视培训和交流。
三、需求建模需求建模是软件需求工程中非常重要的环节，这个步骤的质量将直接决定软件的质量。
需求建模常常涉及以下内容：1.需求规格说明：需求规格说明是将客户的需求及其应用映射到构建系统的具体实现，需要建立系统的需求模型和响应库，使得需求是清晰的，对开发过程中的问题具有及时的支持。
需求捕获最佳实践
文档考古：概述
文档考古：最贴近实现的技术 利：能详细、直观地对数据流细节进行了解与分析。 弊：易陷入文山书海之中不可自拔， 甚至常引起误导。 要点：应该尽量让客户提供写有真 实数据的文档。 特点：从旧的工作材料中挖掘新的需求 检查收集的文档 ，从中找出名词，或 “东西”，包括列标题、命名的表格区域 涉及内容：文档、打印输出、清单、 手册、屏幕等
文档考古：常用思考点
此物的目的是什么？怎么用它？为什么用它？用它做 什么？系统都利用它来做些什么？ 哪些业务事件用到或引用了此物？此物会有一个值吗？ 是数字、代码、数量？如果是这样的话，它属于哪些 东西的组成体？ 此物的用途是什么？ 文档中是否包含了一组重复的事物？如果是这样的话， 这些事物的集合称为什么？
联合开发：概述
联合开发：最理想的技术 利：客户、开发人员直接的头脑风暴，是击破需求盲 点的关键手段。 弊：成本高，如果缺乏控制会变成一次闲扯大会。 要点：需要有一个经验丰富、能够把控大局的主持人。
联合开发：优点
用户访谈：通用问卷
其他需求 > 有必须支持的法律、法规、环境需求或标准吗？ > 你还能想到其他我们应该知道的需求吗? 总结性提问 > 我还有其他问题应该问你吗？ > 如果我还问你其他问题的话，可以打电话给你吗？ 你愿意参加需求审阅吗？ 分析人员总结：面谈后，趁你记得时，总结 出用户/客户确认的三条最高优先级的需求或 问题
需求捕获的各方职责
由需求分析师策划，由需求分析师、用户和其他风险 承担者积极合作完成。 用户、顾客和客户：有责任向需求分析师提供他们的 工作知识 需求分析师：理解用户所说的关于工作的事情，并将 其解释成产品的需求规格说明 > 观察和学习该项工作，从用户角度来理解它 > 用户对某项工作的描述必须作为事实来对待，要发 现工作的本质，而非表象 > 发明完成该工作更好的方法 > 以需求规格说明书和分析模型的方式记录
需求描述最佳实践
需求描述最佳实践 3
用其他需求描述辅助自然语言：某此需求更适于使用 特殊的方式书写，如数学公式、决策表等。 > 主要效益：更加简明、无二义性的需求描述 > 引入成本：很低 > 应用成本：低 定量说明需求：只要有可能，就应该使用定量的数值 说明系统的需求，非功能需求最有可能采用这一点。 > 主要效益：无二义性地表达需求 > 引入成本：低-中 > 应用成本：低-中 > 实施指南：定义表达这些属性的合适的度量；为属 性决定一个合适的值。
歧义术语与改进
可接受、足够：具体定义可接受的内容和系统如何地此进行判断 差不多可行：不要让开发人员来确定什么是可行的 至少、最小、不多于、不超多：指定能够接受的最大值和最小值 在…之间：定义终点是否在此范围内 依赖：描述依赖性的本质，是提供输入？是提前安装支持软件？ 有效的：定义系统如何有效地使用资源，系统执行特定的操作的 速度如何，用户使用系统的容易程度如何 灵活的：描述一种方式 改进的、更好的、更快的、优越的：定量说明 包括、包括但不限于、等等、诸如：项目列表应包含所有可能性 最大化、最小化、最优：陈述对某些参数所接受的最大值和最小 值
2.记录客人，标记为“已入住” 3.提供钥匙 问题：客人忘记归还钥匙 客人需要两套钥匙 任务变体 1a.客人已经预订 问题：客人标识不明确 系统采用最接近匹配算法 （标准的数据输入） 系统打印电子钥匙 每位客人一新钥匙
功能需求的形式 8
场景说明：说明一项或多项用户任务，或要测试的一 个特殊情况，有助于增进开发人员的直觉，通常不作 为需求。 实例：夜班
功能需求的形式 5
屏幕显示及原型：包括屏幕图像及”按钮“的功 能，若经仔细测试可以作为很好的设计层需求 实例：
软件需求工程的最佳实践
软件需求工程的最佳实践第一章导言软件需求工程是软件开发过程中最重要的环节之一，必须深入挖掘用户需求，将其转化为准确的需求规格说明文档，以便于开发人员能够更好地进行软件开发和产品设计。
软件需求的工程化方法可以通过提高需求分析、设计和实施过程中的可重用性、可度量性、可追溯性等方面来实现，最终提高软件产品和开发的质量和效率。
本文介绍软件需求工程的最佳实践，以提高软件需求工程的效率和质量。
第二章软件需求捕获软件需求捕获是开发高质量软件的关键。
为了成功开发软件产品，需要通过收集软件用户和其他相关方面的需求，来建立完整的需求规格说明文档。
在软件需求捕获方面的最佳实践如下：2.1 确定需求来源首先需要确定软件需求的来源，以尽可能完整地了解用户的需求和期望。
来源可能包括用户、客户、业务分析师、产品经理等，可以通过面对面的会议、调查问卷、用户指导手册和现有文献等方式进行。
为了确保数据的准确性和可靠性，应采用多种收集方法并进行交叉验证。
2.2 确定需求识别和跟踪机制为了确保需求的准确性和可靠性，需要建立一个用于识别和跟踪需求的工作流程。
该过程应该包括在整个项目生命周期内对需求的追踪和监控，以确保需求不会被忽略或误解。
2.3 提高开发团队的敏感度为了更好地获取用户需求，需要加强开发人员的与用户的沟通和联系。
开发人员应该了解用户对产品的需求，习惯和期望，并通过专业的市场调研和用户调查来提高对用户行为和需求的理解。
第三章软件需求分析和规格说明需求分析和规格说明是确定软件产品特性的关键步骤。
这里介绍三种最佳实践：3.1 采用适当的需求分析技术需求分析的目的是识别和阐明系统的需求，以建立与用户期望符合的产品。
需求分析技术如加值分析、数据流和数据字典、软件建模方法等，可以帮助开发人员更好地理解和把握软件需求，更好地实现软件开发目标。
3.2 明确并遵循需求规格说明明确需求规格说明书对于开发人员来说是非常重要的，开发人员必须遵循需求规格说明书来确保产品质量和准确性。
软件需求最佳实践SERU过程框架总结
SERU过程框架总结这是参加徐锋的《软件需求最佳实践》课程培训后的再一次总结，笔者在提出SERU过程框架的时候常说到一个观点，就是我们并不缺乏软件工程，需求工程的理论，技术，缺乏的是将这些理论和技术有效的应用到实践。
而作者的SERU过程框架正好是将软件工程理论和具体的需求实践工作真正的结合起来了，个人认为最核心的不是提出了很多重要的需求诫语，更重要的是可以通过SERU框架系统来梳理和回顾我们的需求开发和需求管理活动。
首先对SERU模型的四个字母再做一个说明S:Subject Area，表示子问题域，其核心思想是要通过业务来分解系统，尽量保证业务独立和低耦合。
E:Event，表示业务事件，通过业务事件能够找到流程，通过流程能够找到不同场景和用例。
R:Report，表示报表，统一处理查询，分析和统计类需求。
U:Use Case，表示用例，需求组织的最小单位，到了需求分析阶段的重要活动和产出。
SERU过程框架模型将需求过程分解为了三个阶段，第一个阶段是需求定义，重点是主题域划分和业务事件识别。
第二个阶段是理清需求框架和脉络，重点是通过业务流程图转到具体的领域类图和用例图。
到了第三个阶段重点就是填充需求细节，包括用例的详细编写，界面和交互设计等。
第一阶段-需求定义阶段需求定义阶段强调了一个重点就是高屋建瓴和从顶向下的思路。
当要做一个全新的软件产品的时候，我们首先肯定是进行需求收集和调研，所以书里面专门谈到了需求捕获的最佳实践，包括用户的访谈和调查，现场的观摩等。
同时也提出了类似任务卡片等很好的现场需求捕获工具。
为什么一开始要强调第一阶段对系统的宏观把握和高屋建瓴，因为在做一个全新的软件产品的时候我们很容易收集到大量用户现有的流程，表单，组织架构等信息和资料，但是这样很容易一次的陷入到需求细节中而对企业的业务没有一个宏观的把握。
主题域划分+上下文图，是需求定义阶段的重要输出。
主题域划分主要是从业务的视角来考虑子系统应该如何划以降低业务本身的耦合，在书中也专门提到了主题域划分的思考应该从组织结构为线索，从分管领导找突破以及借鉴典型的业务职能区块等。
需求分析【最佳实践】
需求开发重点整理需求定义1.任务：确定项目的宏观需求，定义项目的业务需求，明确项目的目标和范围。
2.时机在项目立项时完成。
3.需求定义策略3.1破解不清晰的项目目标。
（1）内部寻根：找到项目真正的发起人。
（2）外部溯源：找到外部的激发因素，找到目标参照物。
（例子：老总想做这样一个项目，其实是因为看到别人的某个项目很好，自己也想做一个）3.2找对需求定义着手点：问题，机会具体过程：（1）目标Goals罗列出项目要解决的问题或机会，例：“废品率高”。
（2）问题Problem找到问题产生的根源问题，全部列出来。
（3）可选方案Option针对每个问题，列出可能的解决方案。
（4）建议方案Answer从各种方案中挑选出比较合理的4.问题分析五步法（1）在问题定义上达成共识（定义机会点）。
1.问题定义技巧技巧一：转换例子：马的遍历问题转换成联通图的遍历问题技巧二：本源：发现问题的真正所在例子：“你的等亮着吗？”注意点：1.在确定某问题的解决方案时，一定要思考是否会引发新的问题。
2.直接修改错误，不要用其它方案来弥补错误。
（充电站）（2）理解根本原因，分析问题背后的问题。
方法一：鱼骨图1.选择问题必须有一个具体的问题或结果，（写出问题的定义）2.头脑风暴想出导致问题的所有可能原因，（只想原因，不要考虑解决方案或原因分类）3.确定原因类型对原因进行整理，确定主要原因类型，（类型不超过6种）例子：人，设备，环境，方法，过程，材料......4.分配原因将潜在原因归类到适当的类别中。
（如果原因可以放在多个类别中，说明是个多重原因，或者某个分类有问题。
）5.分析根本原因找到重要原因之后，系统的目标也就明确了。
（3）确定相关人员和用户。
1.项目相关人员：stakeholder“筹码持有人”2.项目健康度评价法：“和那一层客户打交道最多？”A.操作层：出现延误的可能性极大B.中层管理人员：延误比率相对低C.高层管理人员：没有延误可能性（4）定义解决方案界限。
软件需求调研之需求捕获
我们应当怎样做需求调研：需求捕获需求分析工作是一个迭代的过程：需求捕获->需求整理->需求验证->再需求捕获······需求捕获是这个迭代过程的开始，也是整个需求分析工作中最重要的部分。
没有捕获哪来后面的整理与验证工作？但是，非常遗憾，按照我以往的经验，需求捕获是我们最薄弱的环节。
前面我提到的许许多多项目开发的问题都可以归结为需求分析的问题，而许许多多需求分析的问题又都可以归结为需求捕获不完整的问题。
需求捕获是整个需求分析工作中最难把握的一个部分，它不仅仅是一个技术的问题，还涉及到人际交往、沟通、知识理解，以及心理学等一系列问题。
但更让我感到遗憾的是，在我读过的许许多多关于需求分析的书籍中，讨论需求分析与建模的书很多，但讨论需求捕获的书籍却寥寥无几。
确实，要讨论这部分内容，真的已经远远超出了软件开发这个知识领域。
那么，在软件需求捕获过程中，最根本、最容易犯错的问题是什么呢？我认为是一个态度的问题，是采用主动态度去捕获需求，还是采用被动的态度去捕获需求。
如果需求分析人员总是诺诺诺，客户说什么，我们就记什么。
客户处于非常强势的地位，给我们提出了非常多变态、技术难于实现的需求，而我们的需求分析人员却成为记录员，埋头记录客户说的每一句话，不加分析地就直接扔给了开发人员。
这就是采用被动的态度去捕获业务需求的方式。
毫无疑问，这样的需求分析必然将给项目开发的后期带来巨大的风险。
为什么会出现这样的情况呢？经过深入分析我们会发现，从客户嘴中说出来的需求，只是整个软件需求中的冰山一角，还有两类需求需要我们自己去挖掘：客户嘴中没有说出来的需求，和客户压根儿就没有想到的需求。
什么是客户嘴中没有说出来的需求，并不是客户故意卖弄官子不愿说出来，而是在客户所在业务领域已经约定俗称，在他们看来已经是天经地义，根本就不用说出来的业务规则。
然而，作为刚刚涉足该领域的需求人员，他们是不了解这些规则的。
P2-S4-需求描述最佳实践
中程在线信息产业培训网
采用SERU模型的需求规约 --for业务为主 1. 文档概述 1.1 编写的目的 1.2 背景 1.3 定义 1.4 参考资料 2. 任务概述 2.1 业务需求 2.2 Stakeholder利益分析 2.3 用户特点分析 2.4 相关事实与假定 3. 业务模型 3.1 系统概述 [主题域划分] 3.2 主题域1 3.2.1 概述 3.2.2 业务事件 3.2.2.1 业务事件1(包括流程分析、领域类分析、用例分析) 3.2.2.2 业务事件n 3.2.3 报表 3.2.3.1 Report 1(领域类+用例) 3.2.3.2 Report n 3.3 主题域n 4. 具体需求(按主题域组织) 4.1用例模型 4.1.1 UC101 4.1.2 UC102 中程在线信息产业培训网 4.2领域模型 5. 补充规约
中程在线信息产业培训网
非功能需求描述
开放尺度与开放目标：通常要求达到某个数字目标。 实例： > 该产品应能检测超速，并在0.5秒内完成拍照 > 该产品应能够2分钟内计算并显示客户占用情况的预 报表 Planguage表示法：
中程在线信息产业培训网
数据需求表示法
数据模型：E-R模型 > 框图：描述产品内、外的数据 > 非常适合专家使用，但不便于用户使用 数据词典： > 产品内、外数据的文字描述 > 非常适合专家及用户
中程在线信息产业培训网
Volere版需求规约
Part I：项目驱动 1 、项目的目标 该项目工作的用户业务或背景 项目的目标 2 、客户、顾客和其他风险承担者 客户 顾客 其他风险承担者 3 、产品的用户 产品的直接操作用户 对用户设定的优先级 用户参与程度 维护用户和服务技术人员 Part II：产品限制条件 4 、强制的限制条件 解决方案的限制条件 当前系统的实现环境 伙伴应用或协作应用 立即可用的软件 预期的工作地点环境 进度计划限制条件 该产品的财务预算 5 、命名惯例和定义 定义在项目中使用的所有术语，包括同义词 所有包含模型的数据字典 6 、相关事实和假定 事实 假定
P2-S2-需求捕获最佳实践
S2:需求捕获的方法
用户调查：主要用途
搜索某项假设的统计依据：设计一些封闭的问题， 例如“从现有系统中取得客户统计资料的难易程度 ：非常困难、相当困难、容易、非常容易” 搜索意见、建议：询问与用户访谈类似的开放性问 题，例如“日常工作中的三个最大问题是 什么？”，“你对能够更好地支持日 常工作的IT系统有什么建议”。--误 解你的问题，你误解他的回答
抗拒心理：新系统对其利益有
S1:需求捕获策略
构建需求变更的感应器
流程变化、数据变化、业务规则变化、UI变化
变更类型 流程变化快 捕获问题 1. 你们上次组织结构调整是什么时候？ 2. 这个流程以前也是这样的吗？如果不一样，是什么时候的事呢？ 业务规则变化快 1. 这些规则是外部法规，还是内部制定的？ 2. 如果是外部法规，这些法规通常几年会更新一次？ 3. 如果是内部制定的，那么是由哪个部门制定的？依据什么进行调
S1:需求捕获策略
用户需求 “冰山模型 ”与应对
意识到的需求 无意识的需求
未梦想的需求
S1:需求捕获策略
用户心理模型与应对
言过其实心理：说的流程是一种理想化流程，与实际情况 严重不符 越俎代疱心理：对非自己处理的流程津津热道，根据自己 的理解、想像进行肯定的描述
非正事心理：一直忙于工作，无瑕配合需求调研
S2:需求捕获的方法
用户调查：主要困难
相关的问题不能事先决定
问题背后的假设对答案会造成偏颇 > 例如：这功能符合你的期望吗？ > 假设：你有期望，所以这是一个有意义的提问
难以探索一些新的领域，也没有探索新的需要被探 索的领域的交互
难以继续用户的模糊响应
S2:需求捕获的方法