下载文档原格式
软件工程中的软件需求获取与分析方法软件需求获取和分析是软件工程开发过程中至关重要的一环。
它是为了确保软件开发的成功和软件产品能够满足用户的需求而进行的。
本文将介绍几种常用的软件需求获取与分析方法。
一、用户需求访谈用户需求访谈是软件工程中最常用的需求获取方法之一。
它通过与用户进行面对面的交流，了解其对软件产品的期望、功能、界面设计等方面的要求。
在访谈过程中，可以通过提问、观察、记录等方式获取用户的需求信息，并加以整理和分析。
在进行用户需求访谈时，软件工程师需保持沟通的良好态度，尊重用户的观点和需求。
同时，要注意细节，准确记录用户的需求，以便后续的需求分析和软件设计。
二、问卷调查问卷调查是另一种常用的需求获取方法。
通过设计问题，向用户发放问卷，收集用户对软件产品的需求和意见。
问卷调查可以同时面向多个用户，获取多个用户的共同需求和差异化需求。
在设计问卷时，要注意问题的合理性和可操作性。
问题应该具体明确，避免主观和模糊的描述，以便用户能够明确表达自己的需求和意见。
三、原型设计原型设计是一种通过创建软件界面的模型来获取用户需求的方法。
软件工程师可以使用原型设计工具，如Axure、Sketch等，创建界面原型，展示给用户，并征求其意见和建议。
原型设计可以帮助用户更直观地理解软件的功能和操作流程，从而准确地表达自己的需求。
软件工程师可以通过用户的反馈，不断改进原型设计，直到满足用户的需求为止。
四、场景分析场景分析是一种通过模拟用户在特定场景下的需求和行为来获取需求的方法。
软件工程师可以通过观察和记录用户在特定场景中的工作流程，了解他们所需的功能和服务。
在进行场景分析时，要注意选取具有代表性的场景，并与用户充分沟通，确保对场景的理解和模拟的准确性。
通过场景分析，可以更全面地获得用户的需求，为软件开发提供参考。
五、迭代开发迭代开发是一种将软件需求获取与分析过程融入到软件开发过程中的方法。
软件工程师可以在每个开发迭代的过程中，与用户进行交流和需求确认，并根据用户的反馈进行相应的修改和调整。
软件工程需求分析文档（一）引言概述:本文档旨在对软件工程需求分析进行全面解析。
在软件开发过程中，需求分析是一个至关重要的阶段，其中包括了需求获取、需求分析、需求验证等多个环节。
通过本文档的详细阐述，读者将能够全面了解和掌握软件工程需求分析的相关内容，以便在实际项目中能够做到需求准确、明确，并且满足项目的目标和用户需求。
正文:I. 需求获取A. 用户需求的收集1. 与用户进行面对面的交流，获取用户的真实需求2. 收集用户的需求文档和经验总结3. 进行可行性分析，评估用户需求的可行性和优先级B. 系统需求的定义1. 根据用户需求，定义系统的功能和性能等需求2. 确定系统的输入输出流程3. 确定系统的非功能性需求，如安全性、可靠性等II. 需求分析A. 需求分解与分类1. 将系统的总体需求分解为较小的子需求2. 对子需求进行分类，如功能需求、性能需求、界面需求等B. 需求建模1. 使用统一建模语言(UML)等工具对需求进行建模2. 利用用例图、活动图、状态图等进行需求的形式化表示C. 需求规约1. 利用自然语言或规约语言对需求进行明确的描述2. 使用表格、图表等形式记录需求的详细信息III. 需求验证A. 需求审查1. 将需求文档交给相关人员进行审查2. 检查需求的正确性、合理性和可行性B. 需求验证测试1. 设计和执行测试用例，验证需求是否满足2. 检查系统的功能、性能和可靠性是否符合需求IV. 需求变更管理A. 需求变更的评估1. 对需求变更进行评估，包括影响范围和优先级等2. 利用变更控制工具进行需求变更的管理和跟踪B. 需求变更的实施1. 根据变更评估结果，对需求文档进行相应的修改2. 更新系统设计和测试计划等相关文档V. 需求跟踪与管理A. 需求跟踪1. 对需求文档中的每个需求进行编号和跟踪2. 记录需求的状态、变更历史等信息B. 需求管理工具的使用1. 使用需求管理工具对需求进行管理和跟踪2. 利用工具生成需求报告、状态报告等总结：通过本文档的阐述，我们详细介绍了软件工程需求分析的内容和过程。
软件开发岗位实习报告中的软件需求分析方法一、引言在软件开发过程中，软件需求分析是至关重要的一环。
它是指通过与用户和相关利益相关者的沟通，以及对相关业务和系统的理解，把用户需求转化为明确、具体、可操作的软件需求规格说明书的过程。
在软件开发岗位实习报告中，对软件需求分析方法进行详细介绍是非常重要的，下面将分别从需求获取、需求分析与建模以及需求规范化三个方面来进行讲解。
二、需求获取需求获取是软件需求分析的第一步，主要目的是通过与用户和利益相关者的沟通获取对系统功能、性能和一般特征的详细描述。
需要运用一些常用的需求获取技术和方法，包括但不限于：1.面谈：与用户和相关利益相关者进行面对面的交流，深入了解他们的需求和期望。
2.文档分析：对已有的相关文档进行仔细阅读和分析，理解业务背景和需求。
3.问卷调查：通过编写并发送问卷，收集用户和利益相关者的意见和建议。
4.场景分析：通过现场观察或模拟场景，了解软件系统的运行环境和关键流程。
三、需求分析和建模需求获取之后，需要对所获取的软件需求进行分析和建模。
这一步骤旨在将用户的需求转化为系统的需求模型或规范，主要包括以下几个环节：1.需求分析：对需求进行整理、分类、分析和澄清，确保理解正确，消除模糊和冲突之处。
2.需求建模：运用适当的建模工具和技术，将需求转化为系统模型，如用例图、活动图、时序图等。
3.需求验证：通过与用户和利益相关者的反复确认，确保所建立的需求模型是准确且完整的，符合用户的期望。
四、需求规范化需求规范化是对软件需求进行准确且完整的描述，目的是为了让开发人员和测试人员能够理解和实现这些需求。
在实习报告中，对需求规范化的方法进行详细讲解是非常重要的，下面列举几种常用的需求规范化方法：1.自然语言描述：使用自然语言对需求进行详细的文字描述，包括功能需求、非功能需求、性能需求等。
2.用例规范：通过编写用例描述，描述软件系统与用户之间的交互过程，如用例名称、前置条件、基本流程、替代流程等。
引言概述：正文内容：一、需求获取1. 介绍用户需求调研的重要性及流程。
用户需求调研是收集和理解用户需求的关键过程，可以通过面对面的访谈、问卷调查等方法来获取用户需求。
2. 分析用户需求的优先级。
区分用户的主要需求和次要需求，并确定其对软件系统的重要性，以便开发团队能够合理地分配资源。
3. 需求验证和确认。
在需求获取的过程中，将用户需求与实际可行性进行比较，确保需求的准确性和可行性。
二、需求分析1. 分析用户需求的功能性需求。
功能性需求是指软件系统实现的基本功能，开发团队需要仔细分析每个功能需求，并明确其具体实现方式。
2. 分析用户需求的非功能性需求。
非功能性需求包括性能要求、可用性要求、安全要求等，开发团队需要根据具体需求设定标准和指标。
3. 确定用户需求的边界和限制条件。
确定软件系统的界面范围、数据输入输出要求、运行环境等限制条件，以确保软件开发的可行性。
4. 使用案例建模分析用户需求。
使用案例建模是一种将用户需求转化为可执行操作的分析方法，开发团队可以通过绘制用例图和时序图来分析用户需求。
5. 分析用户需求的变更和迭代。
在需求分析过程中，需求的变更是正常的现象，开发团队应该及时跟进变更，并进行相应的调整。
三、需求确认1. 确认用户需求的正确性和完整性。
开发团队通过与用户进行沟通和确认，确保所分析的用户需求正确无误，且没有遗漏。
2. 确定用户需求的优先级和可行性。
在用户需求的确认过程中，开发团队和用户需求方共同讨论需求的优先级和可行性，以合理安排软件开发任务。
四、需求追踪1. 需求追踪的目的和意义。
需求追踪是跟踪需求的变更和开发情况的过程，可以帮助开发团队更好地管理需求和追踪项目进度。
2. 使用需求跟踪矩阵。
需求跟踪矩阵是一种工具，可以将不同的需求与软件开发的迭代过程进行对应，帮助开发团队更好地管理和追踪需求。
3. 管理需求的变更。
在软件开发过程中，需求的变更是正常的现象，开发团队应该及时记录和管理需求的变更，以确保软件开发的顺利进行。
软件工程中的需求分析方法与实践随着信息技术的不断发展，软件已经成为现代社会中不可或缺的一部分。
然而，软件的开发无法离开需求分析与设计的过程，这是确保软件质量的关键步骤。
在软件工程中，需求分析是软件开发过程的第一步，它涉及到对用户需求的收集和分析，以确定软件系统所需的功能和性能特性。
本篇文章将介绍需求分析的基本原则和方法，以及其在软件开发中的实践应用。
一、需求分析基本原则需求分析是识别和收集用户需求的过程，因此，注重客观的认真沟通和交流是非常重要的。
在开展需求分析工作时，应遵循以下几个原则：1. 面向用户：需求分析的主要目的是满足用户的需求，所以需求分析必须面向用户，即尽可能多地了解用户需求，以便能够开发出具有良好适应性的软件。
2. 逐步精确：需求分析是一个逐步精确的过程，需要在收集、分析、整理、验证和确认用户需求的过程中逐步变得更加准确和明晰。
3. 双向沟通：需求分析应该是一个双向沟通过程，既要沟通用户需求，也要让用户理解开发者的开发理念和技术转化能力。
4. 充分交流：应该采用充分交流的方式进行需求分析，例如，面谈、问卷调查、在线讨论等多种方式，以充分获取用户需求，确保用户需求得到充分的理解和识别。
5. 提供可行性分析：开发者需要根据需求分析结果提供可行性分析，以确保要求能够被实现和满足，同时也需要向用户普及相关技术知识和先进的开发经验，从而促进双方合作共赢。
二、需求分析的方法需求分析是一项复杂而且耗时的过程，需要针对不同的软件开发项目采用不同的分析方法和技术。
以下是几种常用的需求分析方法：1. 面谈法：这是最常用的需求分析方法之一。
该方法是通过面对面的交谈来获取用户需求信息，以便详细了解客户的需求和期望。
面谈可以采用个别访谈、专题研讨、焦点小组和工作坊等多种方式。
2. 观察法：这个方法是通过在用户自然情境下观察和记录用户的工作操作，以收集用户需求和功能性需求。
观察法是一种直接而有效的需求分析方法，可以帮助开发人员设计符合用户需求的软件。
需求分析用例范文用例是一种需求分析工具，用于描述系统如何与各种类型的用户（称为参与者）交互以实现特定的目标。
以下是一个需求分析用例的示例，对于一个在线购物网站：用例名称：用户购买商品主要参与者：用户、网站管理员目标：用户能够浏览和购买在线商城中的商品前提条件：用户必须具有有效的账户，并且已经登录到网站成功情况：用户成功选择并购买所需的商品主要流程：1.用户登录到网站，并使用功能浏览商品目录。
2.用户在结果中选择感兴趣的商品。
3.用户查看商品详细信息，包括价格、描述和评价等。
4.用户决定购买该商品，并将其添加到购物车中。
5.用户选择继续购物或者进行结账。
6.如果用户选择继续购物，则返回步骤27.如果用户选择结账，则显示订单确认页面。
8.用户确认订单，并选择支付方式。
9.如果用户选择在线支付，则跳转到支付平台进行支付。
扩展流程：-如果用户在结果页面中没有找到合适的商品，可以进行新的。
-如果用户在浏览商品详细信息时发现误导性的信息，可以向网站管理员举报。
-如果用户对购物车中的商品进行更改或删除，更新购物车并重新计算总价。
-如果用户选择货到付款或其他非在线支付方式，则不需要跳转到支付平台，而是将订单状态设置为待支付。
特殊要求：-网站应提供安全性保护措施，以保护用户的个人信息和支付信息。
-网站应提供订单跟踪功能，以便用户查看订单的状态和物流信息。
这个用例描述了用户购买商品的正常流程以及一些可能发生的异常情况。
它可以帮助开发团队和用户更好地理解交互过程，并指导系统的设计和实施。
除了这个用例，还可以创建其他用例来描述系统的其他功能，例如注册用户、查询订单等。
这有助于全面考虑系统的需求，并确保系统满足用户的期望和需求。
软件需求分析目录一、内容概括 (2)1.1 项目背景 (3)1.2 目的和意义 (3)1.3 定义和缩略语 (4)二、需求获取与分析 (5)2.1 需求获取方法 (6)2.2 需求分析方法 (7)三、功能需求分析 (8)3.1 系统功能概述 (10)3.2 功能模块划分 (11)3.3 功能点描述及优先级划分 (12)四、非功能需求分析 (13)4.1 性能需求 (14)4.2 可靠性需求 (15)4.3 安全性需求 (16)4.4 可维护性需求 (18)4.5 可用性需求 (19)五、界面设计 (20)5.1 用户界面设计原则 (22)5.2 系统界面结构设计 (23)六、数据库设计 (24)6.1 数据库概念设计 (25)6.2 数据模型设计 (26)七、系统架构设计 (28)7.1 系统总体架构设计 (29)7.2 模块划分与接口设计 (31)八、开发计划与进度安排 (32)8.1 项目开发计划 (34)8.2 项目进度安排表 (35)九、测试策略与测试计划 (36)9.1 测试策略制定原则 (36)9.2 测试用例设计方法 (38)9.3 测试计划制定原则 (39)十、项目总结与展望 (40)一、内容概括功能需求：详细列出软件应实现的所有功能，包括业务流程、系统功能、输入输出等，并对每个功能进行描述。
性能需求：明确软件在运行过程中需要满足的性能指标，如响应时间、处理速度、内存占用等。
用户界面需求：描述软件的用户界面设计，包括界面风格、操作流程、菜单结构等，确保用户能够便捷地使用软件。
安全性需求：阐述软件在数据安全、信息安全、用户权限管理等方面的要求，保障用户数据安全和软件运行安全。
可靠性和可用性需求：说明软件在稳定性、容错性、可维护性等方面的要求，确保软件能够满足用户的持续使用需求。
支持和服务需求：描述用户在使用过程中可能需要的支持和服务，包括帮助文档、在线支持、培训等。
法规和标准符合性：确保软件的开发和运营符合相关法律法规和行业标准的要求。
软件需求分析引言软件需求分析是软件开发过程中的关键步骤之一，它对于确保软件开发项目的成功具有重要意义。
软件需求分析的主要目的是识别、整理和定义用户对软件的需求，以便于开发团队能够设计和实施出符合用户期望的软件系统。
本文将介绍软件需求分析的基本概念、流程以及常用的技术方法。
软件需求分析的概念软件需求分析是指对软件系统进行彻底的调查和研究，以确定用户和其他相关利益相关方对软件的需求。
在软件开发生命周期的早期阶段，软件需求分析将帮助开发团队准确定义软件系统的功能、性能和约束条件。
通过软件需求分析，开发团队可以更好地理解用户的需求，从而提供出更好的解决方案。
软件需求分析的流程1. 需求获取软件需求的获取是软件需求分析的起点。
其中，主要包括用户访谈、问卷调查、观察和文档分析等方法。
用户访谈是一种常用的需求获取技术，通过与用户直接对话，开发团队可以了解到用户对软件系统的期望、功能需求以及其他相关信息。
问卷调查可以借助在线工具，广泛搜集用户的需求信息。
观察则是观察用户在实际使用环境中的行为，从中获取对软件的需求。
2. 需求分析在需求获取阶段完成后，需求分析阶段将开始将这些需求进行归类、整理和分析。
首先，将收集到的需求划分为功能需求和非功能需求，进一步进行细分和梳理。
其次，将需求与系统的约束条件（如时间、成本和技术限制等）进行评估和匹配，以确定哪些需求是可实现的，哪些需求是不可行的。
最后，需求分析阶段还包括建立需求文档，并与利益相关方进行确认和批准。
3. 需求规格说明需求规格说明是将分析出的需求进行详细描述的过程。
在需求规格说明阶段，开发团队将采用适当的模型、工具和方法来规范和记录需求。
其中，用例图、数据流图和状态转移图等模型可以帮助团队更加清晰地描述需求的功能和交互过程。
此外，还可以使用面向对象分析（OOA）和面向对象设计（OOD）等方法来进行需求的建模和分析，以确保需求的准确性和一致性。
4. 需求验证与确认需求验证与确认是对需求进行评审、验证和确认的过程。
软件开发中的需求分析需求分析在软件开发过程中起着至关重要的作用。
它是为了确保开发出的软件系统能够准确地满足用户的需求而进行的一项关键活动。
在软件开发中，需求分析通常包括需求获取、需求分析、需求规格化和需求验证等阶段。
本文将深入探讨软件开发中的需求分析过程及其重要性。
一、需求获取需求获取是需求分析的第一步，它涉及到与用户、客户和其他相关利益相关者沟通和交流。
通过与相关方的讨论、面对面的会议、用户调查和研究等方法，需求工程师可以获取到关于软件系统的需求信息。
需求获取阶段的关键是确保准确和详尽地收集到用户的需求，避免遗漏或误解。
二、需求分析需求分析是根据需求获取阶段获得的需求信息，对需求进行细致详细的分析和整理。
在这个阶段，需求工程师将需求进行分类、归纳和整理，提炼出系统要实现的功能和性能需求。
同时，还要对需求之间的关系进行理解和分析，绘制用例图、数据流图等辅助工具来描述需求与系统功能之间的关系。
三、需求规格化需求规格化是将需求分析结果进行形式化描述的过程。
在这个阶段，需求工程师将需求用技术规范语言编写成软件需求规格说明书，以确保需求的准确性、一致性和可跟踪性。
需求规格化常用的工具包括用例规约、活动图、状态转换图等。
这些规格说明书将为软件的设计、编码、测试和验收提供有效的依据。
四、需求验证需求验证是确认需求规格是否满足用户期望的过程。
在这个阶段，开发团队会将需求规格与用户进行确认对比，确保需求规格符合用户的实际需求。
需求验证的方法包括原型验证、演示验证、测试验证等。
通过需求验证，可以及早发现和修正需求规格中的问题，减少后期解决问题的成本和风险。
需求分析在软件开发中的重要性不容忽视。
它能够帮助开发团队准确理解用户需求，避免开发出与用户期望不符的软件。
通过需求分析，可以提前发现和消除需求中的冲突和不一致性，从而减少项目的延期和返工。
此外，良好的需求分析还能够提高开发团队的工作效率，降低开发成本。
总结起来，软件开发中的需求分析是确保软件系统开发成功的关键环节。
软件测试中的需求与用例分析软件测试是软件开发生命周期中的一个重要环节，通过测试可以确保软件产品的质量和稳定性。
在进行软件测试时，需求与用例分析是不可或缺的步骤。
本文将探讨软件测试中的需求与用例分析过程及其重要性。
1. 概述在软件测试过程中，需求与用例分析是确定要测试的功能和预期结果的关键步骤。
需求分析是为了收集、明确和记录用户需求和技术要求。
而用例分析是根据这些需求，编写测试用例来验证软件的功能是否实现了这些需求。
2. 需求分析需求分析是软件测试的起点，通过需求分析可以准确定义软件的功能和目标。
在需求分析阶段，我们需要收集用户的需求，与相关人员沟通，明确软件的功能、性能和界面等方面的要求。
根据不同的软件类型和应用场景，需求分析可以分为功能性需求、非功能性需求等。
2.1 功能性需求功能性需求是指软件应该具备完成特定任务的能力。
在需求分析阶段，我们需要详细列出软件所应实现的功能点，并与相关人员进行确认和同意。
同时，我们需要定义这些功能点的输入数据、输出数据和预期结果。
2.2 非功能性需求非功能性需求是指软件在使用过程中的性能、安全性、可靠性等方面的要求。
在需求分析阶段，我们需要列出与软件性能相关的需求，如响应时间、并发用户数、系统容量等。
同时，我们需要考虑软件的安全性，包括用户权限管理、数据加密等。
软件的可靠性也是非功能性需求的一部分，包括软件的稳定性、可恢复性等。
3. 用例分析用例分析是需求分析的延伸，通过编写测试用例来验证软件是否满足用户需求。
测试用例是一系列输入、操作和预期结果的组合，可以用来检测软件是否按照需求工作。
3.1 编写测试用例在编写测试用例时，我们需要根据需求分析的结果，明确每个功能点的输入数据和预期结果。
我们可以采用不同的测试技术，如黑盒测试、白盒测试等，来编写测试用例。
测试用例应尽可能详细和全面，覆盖软件的各个功能点和边界条件。
3.2 执行测试用例在执行测试用例时，我们需要按照编写的测试用例步骤，输入相应的数据和操作软件。
需求分析概述—需求获取及用例使用需求获取(requirement elicitation)是需求工程的主体。
对于所建议的软件产品，获取需求是一个确定和理解不同用户类的需要和限制的过程。
获取用户需求位于软件需求三个层次的中间一层。
业务需求决定用户需求，它描述了用户利用系统需要完成的任务。
从这些任务中，分析者能获得用于描述系统活动的特定的软件功能需求，这些系统活动有助于用户执行他们的任务。
需求获取是在问题及其最终解决方案之间架设桥梁的第一步。
获取需求的一个必不可少的结果是对项目中描述的客户需求的普遍理解。
一旦理解了需求，分析者、开发者和客户就能探索出描述这些需求的多种解决方案。
参与需求获取者只有在他们理解了问题之后才能开始设计系统，否则，对需求定义的任何改进，设计上都必须大量的返工。
把需求获取集中在用户任务上—而不是集中在用户接口上—有助于防止开发组由于草率处理设计问题而造成的失误。
需求获取、分析、编写需求规格说明和验证并不遵循线性的顺序，这些活动是相互隔开、增量和反复的。
当你和客户合作时，你就将会问一些问题，并且取得他们所提供的信息(需求获取)。
同时，你将处理这些信息以理解它们，并把它们分成不同的类别，还要把客户需求同可能的软件需求相联系(分析)。
然后，你可以使客户信息结构化，并编写成文档和示意图(说明)。
下一步，就可以让客户代表评审文档并纠正存在的错误(验证)。
这四个过程贯穿着需求分析的整个阶段。
需求获取可能是软件开发中最困难、最关键、最易出错及最需要交流的方面。
需求获取只有通过有效的客户—开发者的合作才能成功。
分析者必须建立一个对问题进行彻底探讨的环境，而这些问题与产品有关。
为了方便清晰地进行交流，就要列出重要的小组，而不是假想所有的参与者都持有相同的看法。
对需求问题的全面考察需要一种技术，利用这种技术不但考虑了问题的功能需求方面，还可讨论项目的非功能需求。
确定用户已经理解：对于某些功能的讨论并不意味着即将在产品中实现它。
对于想到的需求必须集中处理并设定优先级，以避免一个不能带来任何益处的无限大的项目。
需求获取是一个需要高度合作的活动，而并不是客户所说的需求的简单誊本。
作为一个分析者，你必须透过客户所提出的表面需求理解他们的真正需求。
询问一个可扩充(open-ended)的问题有助于你更好地理解用户目前的业务过程并且知道新系统如何帮助或改进他们的工作。
调查用户任务可能遇到的变更，或者用户需要使用系统其它可能的方式。
想像你自己在学习用户的工作，你需要完成什么任务?你有什么问题?从这一角度来指导需求的开发和利用。
还有，探讨例外的情况：什么会妨碍用户顺利完成任务?对系统错误情况的反映，用户是如何想的?询问问题时，以“还有什么能”,”当?时，将会发生什么”“你有没有曾经想过”,“有没有人曾经”为开头。
记下每一个需求的来源，这样向下跟踪直到发现特定的客户。
有些时候，尝试着问一些“愚蠢”的问题也有助于客户打开话匣子。
如果你直接要求客户写出业务是如何实现的，客户十有八九无法完成。
但是如果你尝试着问一些实际的问题，例如：“以我的理解，你们收到订单后，会...”。
客户立刻就会指出你的错误，并滔滔不绝的开始谈论业务，而你，就在一边仔细的聆听吧。
这一招就叫做“抛砖引玉”。
需求讨论会上必须要使用笔记本电脑，还要指定一个打字熟练的人把所有的讨论记录下来，记录的同时还要做一定的整理。
如果不这样做，那么你结束会议的时候就会发现，所有的讨论只剩下一个模糊的印象，需求对你来说仍然是一件遥远的事情。
在座谈讨论之后，记下所讨论的条目(item)，并请参与讨论的用户评论并更正。
及早并经常进行座谈讨论是需求获取成功的一个关键途径，因为只有提供需求的人才能确定是否真正获取需求。
进行深入收集和分析以消除任何冲突或不一致性。
尽量把客户所持的假设解释清楚，特别是那些发生冲突的部分。
从字里行间去理解以明确客户没有表达清楚但又想加入的特性或特征。
Gause 和Weinberg(1989)提出使用“上下文无关问题”—这是一个高层次的问题，它可以获取业务问题和可能的解决方案的全部信息。
客户对这些问题的回答诸如“产品要求怎样的精确度”或“你能帮我解释一下你为什么不同意某人的回答吗?”这些回答可以更直接地认识问题，而这是封闭(close-end)问题所不能做到的。
需求获取利用了所有可用的信息来源，这些信息描述了问题域或在软件解决方案中合理的特性。
一个研究表明：比起不成功的项目，一个成功的项目在开发者和客户之间采用了更多的交流方式(Kiel and Carmel 1995)。
与单个客户或潜在的用户组一起座谈，对于业务软件包或信息管理系统(MIS)的应用来说是一种传统的需求来源。
直接聘请用户进行获取需求的过程是为项目获得支持和买入(buy-in)的一种方式。
尽量理解用户用于表述他们需求的思维过程。
充分研究用户执行任务时作出决策的过程，并提取出潜在的逻辑关系。
流程图和决策树是描述这些逻辑决策途径的好方法。
在需求获取的过程中，你可能会发现对项目范围的定义存在误差，不是太大就是太小。
如果范围太大，你将要收集比真正需要更多的需求，以传递足够的业务和客户的值，此时获取过程将会拖延。
如果项目范围太小，那么客户将会提出很重要的但又在当前产品范围之外的需求。
当前的范围太小，以致不能提供一个令人满意的产品。
需求的获取将导致修改项目的范围和任务，但作出这样具有深远影响的改变，一定要小心谨慎。
正如经常所说的，需求主要是关于系统做什么，而解决方案如何实现是属于设计的范围。
这样说虽然很简洁，但似乎过于简单化。
需求的获取应该把重点放在“做什么”上，但在分析和设计之间还是存在一定的距离。
你可以使用假设“怎么做”来分类并改善你对用户需求的理解。
在需求的获取过程中，分析模型、屏幕图形和原型可以使概念表达得更加清楚，然后提供一个寻找错误和遗漏的办法。
把你在需求开发阶段所形成的模型和屏幕效果看成是方便高效交流的概念性建议，而不应该看成是对设计者选择的一种限制。
需求获取讨论会中如果参与者过多，就会减慢进度。
人数大致控制在5到7人是最好的。
这些人包括客户、系统设计者、开发者和可视化设计者等主要工程角色。
相反地，从极少的代表那里收集信息或者只听到呼声最高、最有舆论影响的用户的声音，也会造成问题。
这将导致忽视特定用户类的重要的需求，或者其需求不能代表绝大多数用户的需要。
最好的权衡在于选择一些授权为他们的用户类发言的产品代表者，他们也被同组用户类的其它代表所支持。
没有一个简单、清楚的信号暗示你什么时候已完成需求获取。
当客户和开发者与他们的同事聊天、阅读工业和商业上的文献及在早上沐浴时思考时，他们都将对潜在产品产生新的构思。
你不可能全面收集需求，但是下列的提示将会暗示你在需求获取的过程中的返回点。
1. 如果用户不能想出更多的使用实例，也许你就完成了收集需求的工作。
用户总是按其重要性的顺序来确定使用实例的。
2. 如果用户提出新的使用实例，但你可以从其它使用实例的相关功能需求中获得这些新的使用实例，这时也许你就完成了收集需求的工作。
这些新的使用实例可能是你已获取的其它使用实例的可选过程。
3. 如果用户开始重复原先讨论过的问题，此时，也许你就完成了收集需求的工作。
4. 如果所提出的新需求比你已确定的需求的优先级都低时，也许你就完成了收集需求的工作。
5. 如果用户提出对将来产品的要求，而不是现在我们讨论的特定产品，也许你就完成了收集需求的工作。
以上知识大致上讨论需求分析应该如何做，实际上对于需求分析的方法有很多很多，已经形成了一定的理论，当然这种理论比较偏向与方法学，而方法学的应用主要还是要靠个人。
所以，大家在实际应用的时候，不妨结合自己的实际，有选择性的采用一些方法，那你就是成功的。
多年来，分析者总是利用情节或经历来描述用户和软件系统的交互方式，从而获取需求(McGraw and Harbison 1997)。
Ivar Jacobson(1992)把这种看法系统地阐述成用例(用例)的方法进行需求获取和建模。
虽然用例来源于面向对象的开发环境，但是它也能应用在具有许多开发方法的项目中，因为用户并不关心你是怎样开发你的软件。
而最重要的，用例的观点和思维过程带给需求开发的改变比起是否画正式的用例图显得更为重要。
注意用户要利用系统做什么远远强于询问用户希望系统为他们做什么这一传统方法。
用例的重要功能是用画用例图的功能来鉴别和划分系统功能。
它把系统分成角色(actor)和用例(用例)。
角色(actor)表示系统用户能扮演的角色(role)。
这些用户可能是人，可能是其他的计算机一些硬件或者甚至是其它软件系统，唯一的标准是它们必须要在被划分进用例的系统部分以外。
它们必须能刺激系统部分并接收返回。
用例描述了当角色给系统特定的刺激时系统的活动。
这些活动被文本描述。
它描述了触发用例的刺激的本质，输入和输出到其他活动者，和转换输入到输出的活动。
用例文本通常也描述每一个活动在特殊的活动线时可能的错误和系统应采取的补救措施。
这样说可能会非常复杂，其实一个用例描述了系统和一个角色(actor)的交互顺序。
用例被定义成系统执行的一系列动作，动作执行的结果能被指定角色察觉到。
用例可以:用例捕获某些用户可见的需求，实现一个具体的用户目标。
用例由角色激活，并提供确切的值给角色。
用例可大可小，但它必须是对一个具体的用户目标实现的完整描述。
在UML中，用例表示为一个椭圆。
角色是指用户在系统中所扮演的角色。
其图形化的表示是一个小人。
在某些组织中很可能有许多角色实例(例如有很多个销售员)，但就该系统而言，他们均起着同一种作用，扮演着相同的角色，所以用一个角色表示。
一个用户也可以扮演多种角色。
例如，一个高级营销人员既可以是贸易经理，也可以是普通的营销人员;一个营销人员也可以是售货员。
在处理角色时，应考虑其作用，而不是人或工作名称，这一点是很重要的。
我们使用不带箭头的线段将角色与用例连接到一起，表示两者之间交换信息，称之为通信联系。
角色触发用例，并与用例进行信息交换。
单个角色可与多个用例联系;反过来，一个用例可与多个角色联系。
对同一个用例而言，不同角色有着不同的作用：他们可以从用例中取值，也可以参与到用例中。
需要注意的是角色在用例图中是用类似人的图形来表示，尽管执行的，但角色未必是人。
例如，角色也可以是一个外界系统，该外界系统可能需要从当前系统中获取信息，与当前系统有进行交互。
一个用例可能包括完成某项任务的许多逻辑相关任务和交互顺序。
因此，一个用例是相关的用法说明的集合，并且一个说明(scenario)是用例的实例。
这种关系就像是类和对象的关系。
在用例中，一个说明被视为事件的普通过程(normal course)，也叫作主过程，基本过程，普通流，或“满意之路”(happy path)。
