第11章 软件需求工程
软件需求工程
软件需求工程在当今数字化的时代，软件如同空气一般渗透到我们生活的方方面面。
从智能手机上的各种应用程序，到企业内部复杂的业务系统，软件的身影无处不在。
然而，要开发出一款成功的软件，并非仅仅依靠编程技术就能实现，其中至关重要的一环便是软件需求工程。
软件需求工程，简单来说，就是确定软件系统需要做什么的过程。
它就像是建筑工程中的蓝图设计，只有在清晰明确了需求之后，后续的开发工作才能有条不紊地进行。
如果在需求阶段出现了偏差或者模糊不清，那么就如同在没有稳固地基的情况下建造高楼，随时可能面临倒塌的危险。
软件需求工程的第一步是需求获取。
这可不是一件轻松的事情，它需要需求工程师与各种利益相关者进行有效的沟通和交流。
这些利益相关者可能包括最终用户、客户、管理人员、技术人员等等。
他们对于软件系统有着不同的期望和需求，而需求工程师的任务就是从这些纷繁复杂的声音中，提取出真正有价值的信息。
比如说，在开发一款在线购物软件时，用户可能会希望界面简洁美观、操作方便快捷；商家则可能更关注订单管理、库存控制和客户数据分析等功能；而技术人员则需要考虑系统的安全性、稳定性和可扩展性。
需求工程师需要倾听各方的意见，理解他们的业务流程和痛点，通过访谈、问卷调查、观察等方法，尽可能全面地获取需求信息。
获取到需求之后，接下来就是需求分析。
这一阶段需要对收集到的需求进行深入的理解和梳理，去除冗余和模糊的部分，将其转化为清晰、准确、可度量的需求规格说明。
需求分析就像是对一堆杂乱的拼图碎片进行整理和分类，找出它们之间的内在联系和逻辑关系，最终拼凑出一幅完整的画面。
在需求分析过程中，常常会用到一些工具和技术，比如用例图、数据流图、数据字典等。
以用例图为例，它可以直观地展示系统的功能和用户与系统之间的交互过程，帮助开发团队更好地理解系统的行为和功能。
需求规格说明是需求工程的重要产出物之一。
它详细描述了软件系统需要具备的功能、性能、数据、安全等方面的要求，是开发团队进行设计、编码和测试的重要依据。
软件需求工程
软件需求工程软件需求工程是指将用户需求转化为明确的和可行的软件需求规范的过程。
它是软件开发生命周期中非常重要的一步，决定了项目的成功与否。
本文将从需求工程的定义和目标、需求获取方法、需求分析和整理、需求规格化等方面进行探讨。
一、需求工程的定义和目标需求工程是指在软件工程中，从用户需求出发、对需求进行获取、分析、规格化和变更控制的一系列活动集合。
需求工程的目标在于确保软件开发团队和用户之间的需求达成一致，并深入挖掘用户真正的需求，从而产出一个高质量、可靠的需求规格。
二、需求获取方法需求获取是指收集用户需求的过程，根据不同的项目和情况，可以采用以下几种常见的需求获取方法：1. 面谈法：工程师和用户面对面进行沟通，通过问答的方式获取用户的需求。
2. 观察法：直接观察用户在使用现有系统或业务流程中的行为，从中捕捉用户的需求。
3. 问卷法：设计问卷并发放给用户，通过用户填写的问卷来获取用户需求。
4. 原型法：根据初步的用户需求，制作出原型，供用户参考和反馈，进一步完善需求。
三、需求分析和整理需求分析主要是对收集到的用户需求进行梳理、分类和分析，确保需求的完整性和可行性。
需求整理是将需求进行排序、分类，以及去除重复、冲突等问题，形成一个清晰明确的需求列表。
在需求分析和整理的过程中，可以采用用例图、数据流图、状态转换图等工具帮助分析和整理需求。
这些工具可以帮助识别需求之间的关系和依赖，以及对需求进行更加深入的理解。
四、需求规格化需求规格化是指将用户需求转化为明确的需求规格文档。
需求规格化的主要目标是准确地描述软件系统的功能、性能、接口等方面，为开发团队提供清晰明确的开发目标。
在需求规格化的过程中，可以使用自然语言描述、UML建模语言、流程图等方法，将用户需求转化为符合工程规范的需求规格文档。
需求规格文档应该包括详尽的需求描述、需求的优先级、需求的变更控制等内容，使开发人员能够准确理解和开发。
五、需求验证与变更控制需求验证是指对需求规格进行检查，确保需求规格的准确性和完整性。
软件需求工程
软件需求工程在当今数字化的时代，软件无处不在，从我们日常使用的手机应用程序，到企业级的复杂业务系统，软件已经成为我们生活和工作中不可或缺的一部分。
而在软件开发的过程中，有一个至关重要的环节，那就是软件需求工程。
软件需求工程，简单来说，就是确定软件系统需要实现哪些功能、达到哪些性能指标、满足哪些用户需求的过程。
它就像是一座建筑的蓝图，如果蓝图不准确或者不完整，那么建造出来的建筑可能就会存在各种问题，甚至成为一座“危楼”。
同样，如果软件需求没有被清晰、准确地定义，那么开发出来的软件很可能无法满足用户的期望，导致项目的失败。
那么，软件需求工程具体包括哪些内容呢？首先是需求获取。
这就像是一场寻宝之旅，开发人员需要通过各种途径，如与用户交流、观察用户的工作流程、分析市场需求等，来获取用户对软件的期望和要求。
在这个过程中，开发人员需要保持敏锐的洞察力和良好的沟通能力，以便能够从用户那里获取到最真实、最有用的信息。
接下来是需求分析。
获取到的需求往往是零散、模糊的，就像一堆未经雕琢的璞玉。
需求分析的任务就是对这些需求进行整理、分类、细化和验证，去除其中的不合理和不明确之处，将其转化为清晰、准确、可度量的软件需求规格说明。
这需要开发人员具备扎实的业务知识和逻辑思维能力，能够从复杂的需求中找出核心问题，并提出合理的解决方案。
然后是需求规格说明的编写。
这是软件需求工程的重要成果之一，它是一份详细的文档，描述了软件系统需要实现的功能、性能、数据、安全等方面的要求。
需求规格说明应该具有准确性、完整性、一致性、可验证性和可修改性等特点，以便为后续的软件开发工作提供明确的指导。
在需求规格说明编写完成后，还需要进行需求验证。
这就像是对一件产品进行质量检测，通过评审、测试等手段，确保需求规格说明的正确性和有效性。
如果在验证过程中发现问题，就需要及时对需求进行修改和完善。
除了上述的几个主要阶段，软件需求工程还涉及到需求管理。
需求是会随着时间和环境的变化而发生改变的，因此需要对需求的变更进行有效的管理，包括变更的提出、评估、审批、实施和跟踪等。
软件需求工程
软件需求工程软件需求工程是指在软件开发过程中对软件需求进行系统化、规范化的管理和处理的过程。
它包括软件需求的获取、分析、规范化、验证和管理等环节。
在整个软件开发生命周期中，软件需求工程起着至关重要的作用，它直接影响到软件开发质量和项目进展。
一、软件需求工程的定义软件需求工程是指在软件开发过程中对软件需求进行系统化、规范化的管理和处理的过程。
它包括软件需求的获取、分析、规范化、验证和管理等环节。
软件需求工程的目标是确保软件开发团队理解用户需求，并能够根据用户需求开发出满足其期望的软件产品。
二、软件需求工程的重要性软件需求工程在软件开发过程中具有重要的地位和作用，主要体现在以下几个方面：1. 确保项目顺利进行：软件开发过程中，需求不明确或者需求变更频繁往往会导致项目进展受阻。
通过对软件需求进行有效的工程化管理，可以确保项目按计划进行，减少开发过程中的不确定性。
2. 提高软件质量：软件需求工程能够对软件需求进行全面、准确的描述和规范化处理，使开发团队对用户需求有明确的认识。
这样可以避免开发过程中的误解和偏差，从而提高软件的质量和用户满意度。
3. 降低开发成本：软件需求工程能够在软件开发初期就发现和解决潜在的问题，避免在后期进行大幅度的修改和调整。
这样可以降低开发成本，并节约开发团队的时间和资源。
4. 加强项目管理：软件需求工程作为软件开发的基础，能够帮助项目经理对项目进展、人力资源和进度进行有效的管理。
通过对软件需求的追踪和管理，项目经理能够及时发现问题并做出相应的调整和决策。
三、软件需求工程的主要过程软件需求工程包含以下主要过程：1. 需求获取：通过与用户交流、访谈、需求调研等方式，获取用户的需求信息。
需求获取是软件需求工程的第一步，也是最关键的一步，它直接关系到后续工作的开展和软件开发质量。
2. 需求分析：在需求获取的基础上，进行需求分析工作，主要包括需求划分、需求描述、需求模型化等。
通过需求分析，将用户需求转化为开发团队所理解的形式，为后续的开发工作提供参考依据。
软件需求工程
软件需求工程随着现代社会信息技术的快速发展，软件需求工程作为软件开发的第一关键环节，越来越受到人们的重视。
所谓软件需求工程，是指将用户或客户对软件的需求转化成软件系统的所有功能和性能要求的过程，是确保软件系统最终的用户需求和实际应用需求之间的一项重要的技术和程序。
软件需求工程的目的，就是在开发软件系统前，尽可能完整地了解和分析用户的需求，并根据这些需求来指导软件系统设计、开发和测试的整个过程。
好的软件需求工程能够确保软件系统的功能和性能满足用户的期望，同时可以让软件开发人员和用户之间建立起良好的沟通和合作关系，从而更好地实现软件开发的目标。
软件需求工程的过程大致可以分为需求识别、需求分析、需求规格和需求确认四个阶段。
首先，需求识别是软件需求工程中最重要的环节之一。
它的主要目标是，在开发软件系统前，充分了解并识别用户的需求，准确地确定软件系统的使用范围和用户群，为后续的需求分析和规格制定打下坚实的基础。
在需求识别的过程中，要充分考虑用户的主要需求和目标、系统使用环境和约束条件等相关因素，发现和概述系统中的功能、性能和界面等方面的需求。
其次，需求分析是软件需求工程中的第二个关键环节。
它的主要任务是对用户需求进行进一步分析和细化，分析不同的用户需求之间的关系，确定软件系统的功能模块、依赖关系和图例等方面的需求，为后续的需求规格提供基础。
在需求分析的过程中，需要采取多种形式的需求收集方法，例如面谈、问卷、代码审查等，分析不同需求之间的相互作用和影响，制订具体的软件系统需求规范。
然后，需求规格是软件需求工程中实现用户系统上述需求的纲要和规范。
在软件需求规格制定的过程中，需要制定出一个完整的、清晰明了的需求规格书，并确保该规格书能够精确、完整地描述出软件系统的所有要求和特性。
在制定需求规格书的过程中，需要要明确为每个软件需求规范分配一个唯一的标识，并针对每个需求规范给出相应的检验方法。
最后，关于需求确认，它是软件需求工程中的最后一个环节。
软件需求工程
领料单 申请部门 经理审批
免费样品领用
物资管理部－综合计划
物资管理部－仓库
物资管理部计划 员将有关材料计划
输入系统
计划人员从系统中 打印领料单
综合计划经理对领 料单进行审核
已同意旳领料单
财务部
材料帐务人员从系 统中确认领料
成品发料员进行 签字、发料
财务人员进行 帐务处理
订购货品旳简朴时序图
软件需求工程
软件工程是以借鉴老式工程旳原则、措施，以提升质量，降 低成本为目旳指导计算机软件开发和维护旳工程学科
软件工程旳基本目旳
• 付出较低旳开发成本； • 到达要求旳软件功能； • 取得很好旳软件性能； • 需要较低旳维护费用； • 能按时完毕开发工作，及时交付使用；
错误扩大现象
1400
1200
签和运送订货。 库存系统(Inventory system)—统计企业存货旳软件 记账系统(Accounting system)—统计企业账目旳软件
订单处理用例描述
•订购货品(Place Order)—客户提交新商品订单而且为商品付费。 •取得目录(Get Catalog)—客户要求得到一种目录或产品清单。 •取得订单旳状态(Get Status on Order)—客户得到一种已存在订单 旳状态。
订购货品
订购货品用例图
订购完毕用例图
拟定项目范围
•当分阶段实施项目计划时，要分清优先级，拟定项 目范围。
•拟定需求优先级时，需要考虑你所拟定旳风险和市 场原因。所以“一定要有”不是仅仅基于技术需要， 但 是 可 能 也 会 在 市 场 上 遇 到 风 险 。 对 于 National Widgets企业来说，这可能意味着Web界面是一种订 单处理系统“一定要有”旳原因，因为其他旳邮递企 业都提供这一功能。这一特征是跟上市场竞争旳要求。
软件需求工程
软件需求工程在当今数字化的时代，软件如同无处不在的精灵，渗透到我们生活的方方面面。
从智能手机上的各种应用，到企业内部复杂的业务系统，软件的身影无处不在。
然而，要开发出一款成功的软件，绝非易事。
其中，软件需求工程扮演着至关重要的角色，就如同建筑施工前的蓝图设计，决定了软件的“根基”是否牢固，功能是否满足用户的期望。
那么，什么是软件需求工程呢？简单来说，它是指致力于理解用户需求，并将这些需求转化为清晰、准确、完整的软件规格说明的一系列活动和过程。
这可不是一项简单的任务，它需要涉及众多的环节和参与者，包括用户、业务分析师、开发人员、测试人员等等。
首先，需求获取是软件需求工程的第一步。
这就像是一场探索之旅，要去挖掘用户内心真正的需求。
想象一下，你要为一家餐厅开发一个点餐系统，你不能仅仅满足于知道他们需要一个能点菜的功能，还得了解他们对于菜品分类、菜单展示、订单处理、支付方式等方面的具体要求。
这可能需要与餐厅的经理、服务员、厨师等进行深入的交流，观察他们的工作流程，甚至亲自体验点餐的过程。
在需求获取的过程中，用户往往并不能清晰地表达自己的需求。
他们可能会说“我想要一个方便快捷的系统”，但这到底意味着什么呢？这就需要需求分析师具备敏锐的洞察力和良好的沟通技巧，通过引导式的提问、案例分析等方法，帮助用户将模糊的想法逐渐具体化。
比如，询问用户“方便快捷具体体现在哪些方面？是下单速度快，还是菜品推荐准确？”获取到需求之后，接下来就是需求分析。
这一步就像是对收集到的“原材料”进行加工和提炼。
分析师要对获取到的需求进行梳理，去除重复的、不明确的部分，识别出真正的核心需求，并建立需求之间的关系。
还是以点餐系统为例，通过分析可能会发现，用户对于快速下单的需求背后，是希望系统能够自动识别常客的喜好并推荐菜品，同时提供一键下单的功能。
需求规格说明的编写则是将分析后的需求以一种规范、清晰的方式记录下来。
这就像是给开发人员提供了一份详细的“施工图纸”。
软件工程专业优质课软件需求工程
软件工程专业优质课软件需求工程软件工程专业优质课——软件需求工程软件需求工程是软件工程领域的一门重要课程，它主要关注软件项目中的需求分析、规划与管理。
通过系统地收集、分析和定义用户对软件系统的需求，软件需求工程可以帮助开发团队更好地理解用户需求，并将其转化为可执行的开发计划。
下面将从需求工程的基本概念、流程和关键技术等方面进行论述。
一、需求工程的基本概念软件需求工程是指在软件开发或系统维护过程中，对需求进行收集、分析、定义、验证与管理等一系列活动的过程。
它的目标是构建一个正确、完整、准确、一致和可追踪的需求规格说明，为软件开发提供基础。
需求工程的核心是要确保需求的正确性和完整性。
只有对用户需求进行准确的理解和把握，才能保证软件开发过程中的目标和结果与用户的期望保持一致。
因此，需求工程在整个软件开发过程中具有举足轻重的地位。
二、需求工程的流程需求工程的流程可以分为需求获取、需求分析、需求定义、需求验证和需求管理等五个阶段。
1. 需求获取阶段需求获取阶段主要通过面对面交流、问卷调查、访谈和文献分析等方式，与用户直接沟通以获取需求信息。
在这个阶段中，需求工程师需要充分了解用户的背景、目标和需求，明确项目的范围和目标，以确保需求的准确性和一致性。
2. 需求分析阶段需求分析阶段是对需求进行详细分析和整理的过程。
在这个阶段中，需求工程师会对需求进行分类、排序和整理，以便更好地理解和表达需求。
同时，需求工程师还需要识别需求之间的相互关联和依赖，并找出潜在的冲突和问题。
3. 需求定义阶段需求定义阶段是将需求转化为可执行的设计和规划的过程。
在这个阶段中，需求工程师需要将需求进行详细描述，并明确需求的优先级和可实现性。
同时，还需要与开发团队共同讨论和协商，确立一个合理的开发计划和时间表。
4. 需求验证阶段需求验证阶段是对需求的正确性和完整性进行验证的过程。
在这个阶段中，需求工程师会与用户进行沟通和协商，共同确认和验证需求的准确性和可行性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
第11章软件需求工程在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求分析很少受到重视。
后来，软件开发引入了生命周期的概念，需求分析成为其第一阶段。
随着系统规模的扩大，需求分析与定义在整个系统开发与维护过程中越来越重要，直接关系到系统的成功与否。
人们也逐渐认识到需求分析活动不再仅限于系统开发的最初阶段，而是贯穿于系统开发的整个生命周期。
于是，形成了软件工程的子领域——软件需求工程。
软件需求工程是包括创建和维护软件需求文档所必需的一切活动的过程，可分为需求开发和需求管理两大工作。
需求开发包括需求获取、需求分析、编写需求规格说明书（需求定义）和需求验证四个阶段。
在需求开发阶段需要确定软件所期望的用户类型，获取每种用户类型的需求，了解实际的用户任务和目标，以及这些任务所支持的业务需求。
同时还包括分析源于用户的信息，对需求进行优先级分类，将所收集的需求编写成为需求规格说明书和需求分析模型，以及对需求进行评审等工作；需求管理通常包括定义需求基线、处理需求变更和需求跟踪等方面的工作。
这两个方面是相辅相成的，需求开发是主线，是目标；需求管理是支持，是保障。
11.1 软件需求概述软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。
根据IEEE 的软件工程标准词汇表，软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。
1. 需求的层次简单地说，软件需求就是系统必须完成的事以及必须具备的品质。
需求是多层次的，包括业务需求、用户需求和系统需求，这三个不同层次从目标到具体，从整体到局部，从概念到细节。
（1）业务需求。
业务需求是指反映企业或客户对系统高层次的目标要求，通常来自项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。
通过业务需求可以确定项目视图和范围，项目视图和范围文档把业务需求集中在一个简单、紧凑的文档中，该文档为以后的开发工作奠定了基础。
有关项目范围管理的详细知识，将在20.3节中介绍。
（2）用户需求。
用户需求描述的是用户的具体目标，或用户要求系统必须能完成的任务。
也就是说，用户需求描述了用户能使用系统来做些什么。
通常采取用户访谈和问卷调查等方式，对用户使用的场景（scenarios）进行整理，从而建立用户需求。
有关需求获取方法的详细知识，将在11.2节中介绍；有关场景的详细知识，将在12.3节中介绍。
（3）系统需求。
系统需求是从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。
功能需求也称为行为需求，它规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。
功能需求通常是通过系统特性的描述表现出来的，所谓特性，是指一组逻辑上相关的功能需求，表示系统为用户提供某项功能（服务），使用户的业务目标得以满足；非功能需求是指系统必须具备的属性或品质，又可细分为软件质量属性（例如，可维护性、可维护性、效率等）和其他非功能需求。
有关质量属性的详细知识，将在20.7.1节中介绍；设计约束也称为限制条件或补充规约，通常是对系统的一些约束说明，例如，必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统之下等。
2. 质量功能部署质量功能部署（Quality Function Deployment，QFD）是一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度。
为了达到这个目标，QFD 将软件需求分为三类，分别是常规需求、期望需求和意外需求。
（1）常规需求。
用户认为系统应该做到的功能或性能，实现越多用户会越满意。
（2）期望需求。
用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。
如果期望需求没有得到实现，会让用户感到不满意。
（3）意外需求。
意外需求也称为兴奋需求，是用户要求范围外的功能或性能（但通常是软件开发人员很乐意赋予系统的技术特性），实现这些需求用户会更高兴，但不实现也不影响其购买的决策。
意外需求是控制在开发人员手中的，开发人员可以选择实现更多的意外需求，以便得到高满意、高忠诚度的用户，也可以（出于成本或项目周期的考虑）选择不实现任何意外需求。
11.2 需求获取需求获取是一个确定和理解不同的项目干系人的需求和约束的过程。
需求获取是一件看上去很简单，做起来却很难的事情。
需求获取是否科学、准备充分，对获取出来的结果影响很大，这是因为大部分用户无法完整地描述需求，而且也不可能看到系统的全貌。
因此，需求获取只有通过系统分析师与用户的有效合作才能成功。
系统分析师必须建立一个对问题进行彻底探讨的环境，而这些问题与将要开发的系统有关。
让用户明确了解，对于某些功能的讨论并不意味着即将在系统中实现它。
作为一名系统分析师，掌握各种不同的需求获取技术，并且熟练地在实践中运用它，是十分必要的。
10.2.3节介绍了诸多的详细调查方法，这些调查方法都可以用在需求获取中，本节就一些最常用的需求获取技术进行展开讨论。
11.2.1 用户访谈用户访谈是最基本的一种需求获取手段，其形式包括结构化和非结构化两种。
结构化是指事先准备好一系列问题，有针对地进行；而非结构化则是只列出一个粗略的想法，根据访谈的具体情况发挥。
最有效的访谈是结合这两种方法进行，毕竟不可能把什么都一一计划清楚，应该保持良好的灵活性。
为了进行有效的用户访谈，系统分析师需要在三个方面进行组织，分别是准备访谈、主持访谈和访谈的后续工作。
1. 准备访谈每一次成功的访谈都需要精心的准备。
在准备访谈过程中，首先也是最重要的步骤是确定访谈的目的，其次是确定访谈中应该包括哪些用户。
这两个步骤结合得非常紧密，因此通常一起完成。
参加访谈的用户数量取决于访谈的目的。
通常，最好限制参加访谈的人数。
例如，一次超过3个用户的访谈有可能使得讨论时间变长，这在有时候可能会适得其反。
在很多情况下，系统分析师每次只和一个用户进行访谈，这对中小规模的项目尤其适用。
准备访谈的第三步是为访谈准备一些详细的问题。
系统分析师可以根据已经获得的表格和报表写出一些具体的问题，并作好笔记。
问题可以分为开放式问题和封闭式问题两类。
所谓开放式问题，就是类似于“你如何完成这项功能”的问题，鼓励用户与系统分析师对问题进行讨论和说明；所谓封闭式问题，就是类似于“你每天处理多少张表格”的问题，可以用来获得具体的事实。
一般而言，开放式问题有助于开始对问题进行讨论，并且鼓励用户说明所有的业务过程和业务规则细节。
准备访谈的最后一步是作出最终的访谈安排，并把这些安排通知所有参加者。
具体的时间和地点应该事先征求被访谈者的同意。
如果可能的话，应尽量选择一个安静的地点以避免外界干扰。
每个参加者都应该知道访谈的目的，而且在适当的时候，参加者也应该有机会预览一下将要访谈的问题或材料。
另外，值得注意的是，系统分析师应该在访谈之前进行一些领域相关的知识培训，充分阅读相关材料，以保证自己有较专业的理解与认识，让用户能够信任自己。
2. 访谈过程在具体访谈时，系统分析师及项目组成员一定要准时到达。
可能的话，尽量早到一点。
在访谈的过程中，要做好以下几项工作：（1）限制访谈时间。
当确定了访谈目的并准备好了问题之后，访谈的时间应该控制在90分钟左右。
如果访谈需要更多的时间来覆盖一些其他的问题，比较好的方法是中断本次访谈，并安排另一次访谈，因为举行几次比较短的访谈要比举行一次马拉松式访谈的效果要好得多。
一系列访谈提供了收集各种材料的机会，这些材料将在随后的过程中被不断细化。
在几次比较短的访谈后，系统分析师和被访谈者都将获得对系统的较好理解。
（2）寻找异常和错误情况。
系统分析师要找机会问一些类似于“如果……那会怎么样”的问题，要有意识地去确定所有的特殊情况，并与用户深入探讨。
（3）深入调查细节。
除了寻找意外情况外，系统分析师必须进行深入调查，以确保获得对过程和规则的完全理解。
（4）认真作好记录。
主要包括本人记录、第三人记录或者是录音/录像的形式。
如果采用录音/录像的方式，应该征得被访谈者的同意。
这种方法虽然看上去比较有效，不容易丢失信息，但容易让被访谈者感到紧张，也会给后面的整理工作带来一定的工作量和难度。
因此，手写笔记是一个好主意，好的笔记不仅为下一次访谈的成功奠定基础，而且也为建立分析模型提供了基础。
在访谈时，系统分析师一定要注意措词得当，充分尊重用户。
否则，将会破坏访谈的气氛，从而使访谈的效率大打折扣。
在访谈时，一定要注意保持轻松的气氛，在说话、提问时应该尽量采用易于理解和通俗化的语言，避免使用IT专业术语。
3. 访谈的后续工作后续工作的首要任务是吸收、理解和记录访谈所获得的信息。
通常，系统分析师通过构造业务过程的模型来记录访谈的细节，和项目组其他成员一起复查访谈中发现的结果，然后在一天或至多两天内记录下结果。
在访谈过程中，系统分析师可能会问一些用户回答不上来的问题，不要丢失或遗忘这些问题，这是非常重要的。
根据需要进一步详细说明的问题或者访谈中错过的信息，系统分析师可以生成一张新的问题列表，为下一次访谈作好准备。
另外，为了维持用户的友好和信任关系，应该送给他们一份总结了访谈内容的备忘录。
其中需要提到被访谈者对项目的贡献，并给他们机会澄清可能在访谈期间得出的任何错误回答。
4. 用户访谈的优缺点总的来说，用户访谈具有良好的灵活性，有较宽广的应用范围。
但是，也存在着许多困难，例如，用户经常较忙，难以安排时间；面谈时信息量大，记录较为困难；沟通需要很多技巧，同时需要系统分析师具有足够的领域知识等。
另外，在访谈时，还可能会遇到一些对于企业来说比较机密和敏感的话题。
因此，这看似简单的技术，也需要系统分析师具有丰富的经验和较强的沟通能力。
11.2.2 问卷调查用户访谈最大的难处在于很多关键人员时间有限，不容易安排过多的时间。
而且，如果用户较多，不可能一一访谈。
因此，就需要借助问卷调查，通过精心设计调查表，然后下发到相关的人员手中，让他们填写答案。
这样，就可以有效地克服用户访谈方法中存在的问题。
1. 调查表的制作问卷调查表使系统分析师可以从大量的项目干系人处收集信息，甚至当项目干系人在地理上分布很广时，他们仍然能通过问卷调查表来帮助获取需求。
一张好的问卷调查表要花费大量的时间来进行设计与制作，包括确定问题及其类型、编写问题、设计问卷调查表的格式三个重要活动。
（1）确定问题及其类型。
与用户访谈一样，问卷调查表上使用的基本问题有开放式问题和封闭式问题。
但不同的是，问卷调查表的问题必须非常清楚，组织顺序必须有说服力，必须能够预见用户可能的回答。
（2）编写问题。