需求获取与需求建模
五级建模步骤规则
五级建模步骤规则1. 引言五级建模是一种用于软件开发的系统分析和设计方法。
它提供了一种结构化的方法来描述系统的需求、功能和行为，以及系统组成部分之间的关系。
五级建模步骤规则是在进行五级建模过程中需要遵循的一些规则和指导原则。
本文将详细介绍五级建模步骤规则的内容和要求。
2. 五级建模概述五级建模包括需求获取、需求分析、系统设计、实现和测试这五个阶段。
每个阶段都有其特定的任务和目标，同时也需要遵循一些基本的规则。
3. 需求获取阶段规则需求获取阶段是确定系统需求的过程。
在这个阶段，需要进行用户访谈、问卷调查等活动来收集用户需求。
以下是需求获取阶段的规则： - 确定参与访谈或调查的用户群体，并制定合适的计划。
- 充分理解用户需求，确保准确地收集到用户所期望的功能和特性。
- 记录所有与用户交流过程中得到的信息，包括问题、意见和建议等。
4. 需求分析阶段规则需求分析阶段是对收集到的需求进行分析和整理的过程。
以下是需求分析阶段的规则： - 将用户需求转化为可操作的需求文档，包括功能需求、性能需求、非功能性需求等。
- 确定系统的边界和范围，明确系统与外部环境的接口和交互方式。
- 确定系统的用例，描述系统与用户之间的交互过程。
5. 系统设计阶段规则系统设计阶段是根据需求文档进行系统设计的过程。
以下是系统设计阶段的规则：- 利用适当的建模工具，如UML（统一建模语言），绘制用例图、类图、时序图等来描述系统结构和行为。
- 根据需求文档确定系统模块之间的关系和依赖。
- 确定各个模块之间的接口规范，确保模块之间可以有效地通信和协作。
6. 实现阶段规则实现阶段是将系统设计转化为实际代码的过程。
以下是实现阶段的规则： - 编写高质量、可维护、易于理解和扩展的代码。
- 遵循编码标准和最佳实践，提高代码的可读性和可靠性。
- 进行充分的单元测试和集成测试，确保系统的功能和质量。
7. 测试阶段规则测试阶段是对系统进行全面测试的过程。
需求开发的四个过程
需求开发的四个过程软件开发过程是指在软件开发过程中，从需求分析到软件维护的整个过程。
它涉及到需求的获取、设计、编码、测试、部署、维护等多个阶段。
本文将详细介绍需求开发的四个主要过程：需求获取、需求分析、需求设计和需求验证。
一、需求获取需求获取是软件开发过程中的第一个阶段，它主要涉及到与客户、用户和相关利益相关者沟通，以了解他们对软件系统的需求和期望。
在需求获取阶段，开发团队需要采用一系列的技术和方法，如面谈、问卷调查、访谈、观察等手段来获取需求。
需求获取的目的是确定软件开发的范围和目标，为后续的需求分析提供基础。
需求获取过程中，开发团队需要与客户、用户和相关利益相关者进行沟通，深入了解他们的需求和期望。
在沟通的过程中，开发团队应该关注以下几个方面：1.确定需求的优先级和重要性。
通过和客户、用户和相关利益相关者沟通，可以了解到哪些需求是必须的，哪些是可选的，以及哪些对于系统的功能和性能是最重要的。
2.确定需求的可行性和可实现性。
在需求获取过程中，开发团队需要评估需求的可行性和可实现性。
他们需要确定是否有足够的资源和技术来实现这些需求，以及实现这些需求的成本和风险。
3.确定需求的约束和限制。
在需求获取过程中，开发团队也需要了解到有哪些约束和限制对软件开发过程有影响。
这些约束和限制可以是技术上的，如硬件和软件平台的限制，也可以是非技术上的，如成本和时间的限制。
二、需求分析需求分析是软件开发过程中的第二个阶段，它主要涉及到对需求进行详细的分析和规范。
在需求分析阶段，开发团队需要将从需求获取阶段获得的需求进行整理、分类和分析，以便能够进一步确定系统的功能和性能要求。
在需求分析过程中，开发团队需要进行以下几个方面的工作：2.分类需求。
将需求进行分类，按照不同的功能和性能需求进行划分。
3.分析需求。
对需求进行进一步的分析和解读，以确定系统的功能和性能要求。
4.规范需求。
将需求进行规范化，将其转化为能够被开发团队理解和实现的形式。
需求分析不包括可行性分析
需求分析不包括可行性分析需求分析是指对项目或产品所需要满足的功能和性能进行细致的核查和定义，以确保项目能够满足用户的期望和需求。
它主要关注用户所需求的功能、性能、可靠性、安全性、可维护性等方面，以及不同用户之间的差异化需求。
需求分析是软件开发过程中的重要一步，它直接关系到项目的成功与否。
需求分析主要包括以下几个步骤：1. 需求获取：需求获取是建立起需求分析的基础，它通过与用户的沟通和交流，了解用户的需求，收集相关的信息，并对获取到的需求进行记录和整理。
2. 需求分析：需求分析是对收集到的需求进行深入的分析和理解。
分析人员需要对需求进行分类和归纳，提取出其中的关键需求，并进行进一步的细化和澄清。
需求分析也包括对需求之间的相互关系进行分析和理解。
3. 需求建模：需求建模是通过使用适当的工具和技术，对需求进行形式化的描述和表达。
常用的需求建模工具包括数据流图、用例图、活动图等。
需求建模可以帮助分析人员更好地理解和描述需求，同时也有助于与开发人员和用户之间的沟通和交流。
4. 需求确认：需求确认是指将分析出的需求与用户进行沟通确认，确保需求的准确性和完整性。
在需求确认过程中，可以使用原型、模拟演示等方法来帮助用户更直观地理解和确认需求。
5. 需求文档编写：需求文档是对分析后的需求进行详细的描述和说明，包括需求的功能描述、性能要求、界面设计等。
需求文档是项目进行开发和实施的依据，也是与用户进行需求确认的重要参考。
需求分析的目标是确保项目能够提供满足用户需求的产品或解决方案。
通过需求分析，可以帮助开发团队更好地理解用户需求，避免在开发过程中的用户需求漏洞，提高开发效率和质量。
同时，需求分析也可以帮助用户明确自己的需求，从而更好地参与到项目中，达到双方的共赢。
总之，需求分析是软件开发过程中非常重要的一步，它直接关系到项目的成功与否。
通过需求分析，可以确保项目能够满足用户的需求，提高开发效率和质量。
同时，需求分析也有助于用户更好地理解自己的需求，从而更好地参与到项目中。
需求—需求分析的任务和步骤
2010-09-05需求—需求分析的任务和步骤（转）文章分类:软件开发管理需求分析的任务和步骤任务：1. 通过对问题及其环境的理解，分析和综合，建立分析模型。
2.在完全弄清用户对软件系统的确切需要的基础上，用“软件需求规格说明书（SRS）”把用户的需求表达出来。
分析模型包含问题及其环境所涉及的信息流，处理功能，用户界面，行为模型及设计约束等。
需求说明应该具备准确性，一致性，清楚性，没有二义性，直观，易读和易于修改。
为此应尽量采用标准的图像，表格和简单的符号来表示，使不熟悉电脑的用户也能一目了然。
步骤：1.需求获取：从分析当前系统包含的数据开始，系统需求包括用户对软件功能的需求和界面的需求。
2.需求提炼：分析建模：图像化的分析模型包括数据流图，实体关系图，控制流图，状态转换图，用例图，类对象关系及其行为图等。
除系统模型外，更有系统关联图，创建用户接口原型，确定需求优先级别等。
3.需求描述：编写SRS：统一格式的文档--模板4.需求验证：改善需求中的二义性，不一致的问题。
常规的需求获取方法：1.建立联合分析小组：由用户业务人员，系统分析员和领域专家组成。
2.客户访谈：进一步确定需求。
这个过程需要系统分析员有充分的准备和良好的交流能力。
3.问题分析和确认：去掉错误的，无关的部分，整理有用的内容，以便给用户确认，并在次访谈，如此循环2-5次。
快速原型法：步骤：1.利用各种分析技术和方法，生成一个简化的需求规格说明。
2.对需求规格说明进行必要的检查和修改后，确定原型的软件结构，用户界面和数据结构等。
3.在现有的工具和环境的帮助下快速生成可运行的软件原型并进行测试，改进。
4.将原型提交给用户评估并征求用户的修改意见。
5.重复上述过程，直到原型得到用户的认可。
3.3 分析建模软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。
通过对应问题及其环境的理解与分析，为问题涉及的信息、功能及系统行为建立模型，将用户需求精确化、完全化，最终形成需求规格说明。
系统需求分析与建模
系统需求分析与建模一、引言对于系统的设计与开发来说，需求分析与建模是至关重要的环节。
系统需求分析与建模可以帮助我们全面理解用户的需求，并将其转化为系统功能与特性的清晰描述。
本文将探讨系统需求分析与建模的基本概念、方法和工具，并介绍如何有效地进行需求分析与建模。
二、系统需求分析系统需求分析旨在识别和明确系统的功能、性能和约束条件。
以下是系统需求分析的几个主要步骤：1. 需求获取和理解需求获取是指通过与用户、业务分析师和相关利益相关者的沟通来收集和理解系统需求。
这可以通过面对面的会议、问卷调查、用户访谈等方式进行。
重要的是要确保获取到的需求能够准确反映用户的期望和业务的要求。
2. 需求分析和整理需求分析的目标是将收集到的需求进行分类、整理和整合。
可以使用流程图、数据流图、用例图等工具来分析和描述系统的功能和流程。
同时，需求分析还包括对需求的可行性和优先级进行评估。
3. 需求验证和确认在需求分析的最后阶段，需要与用户和相关利益相关者一起验证和确认需求的准确性和完整性。
这可以通过演示、原型展示或者文档审查等方式进行。
目的是确保需求可以满足用户和业务的期望，并且没有遗漏或冲突。
三、系统需求建模系统需求建模旨在将需求以图形化的方式进行描述和表达，以便于更好地理解和交流。
以下是系统需求建模的几个常用方法：1. 用例图用例图是描述系统与其用户之间交互的图形化表示。
用例图可以帮助我们理解系统的功能与角色，并识别各种场景及其对应的用例。
用例图可以用来指导后续的系统设计和开发工作。
2. 数据流图数据流图是描述系统内部数据流动和处理过程的图形化表示。
数据流图以数据流和处理器为中心，展示了系统的功能和数据流动的过程。
数据流图可以帮助我们识别系统的数据流向和处理逻辑。
3. 状态图状态图是描述系统各个对象的状态及其状态变化过程的图形化表示。
状态图可以帮助我们理解系统的行为和状态转换规则。
通过状态图，我们可以更好地描述系统的状态变化及其对应的操作和事件。
需求建模方法
需求建模方法
需求建模是一个非常重要的过程，它可以帮助开发者捕捉到用户需求，为开发提供指导。
在软件开发过程中，需求建模涉及到对需求的描述、分析、规范和管理等方面，为软件开发提供了一个有序、标准化的方法。
需求建模方法主要包括以下几个方面：
1. 需求获取：通过与用户、项目组成员等进行互动，获取相关需求信息。
2. 需求分析：对需求进行归纳、整理和分类，确定需求的优先级和重要程度，并与系统设计进行协调。
3. 需求规范：将需求转化为规范化的文档或模型，以便于开发人员理解和实现。
4. 需求管理：对需求进行跟踪、变更和评审，保证需求的完整性和正确性。
在需求建模过程中，需求建模者需要对不同的需求进行分析和梳理，确定需求的优先级和重要性，根据需求的不同特点选择不同的建模方法，如用例建模、数据流图、状态转换图等等。
总之，需求建模是软件开发过程中一个非常重要的环节，它可以帮助开发者更好地理解用户需求，为软件开发提供准确、完整的需求描述，从而提高软件开发的效率和质量。
- 1 -。
第6章需求分析与建模
第6章需求分析与建模需求分析与建模是软件开发过程中的重要环节，它是基于用户需求，对系统功能和性能进行细致的分析和建模，以便于后续的系统设计与实现。
本章主要介绍需求分析与建模的概念、方法和工具，以及需求分析与建模的步骤和技巧。
需求分析是软件开发过程中的首要任务，它旨在明确系统的功能需求、性能需求和非功能需求，以及用户对系统的期望和要求。
需求分析包括需求获取、需求分析、需求规格和需求验证等环节。
需求获取是在与用户和其他相关人员的沟通和交流中，获取系统需求的过程。
需求获取的方法有面谈、问卷调查、文档分析、原型演示等。
面谈是需求获取的主要方法，它可以直接与用户进行交流，了解用户的需求和期望。
问卷调查可以广泛收集用户的意见和建议，但需要注意问卷设计和样本选择的合理性。
文档分析是从已有的文档中提取需求信息，如用户手册、竞争产品分析、市场调研报告等。
原型演示可以通过模拟系统的界面和功能，来引导用户提供需求，从而达到需求获取的目的。
需求规格是将需求描述、需求功能和需求级别等信息进行形式化和详细化的过程。
需求规格可以采用自然语言、用例图、数据流图、状态转换图等形式进行描述。
自然语言是最常用的需求规格方法，通过文字和语言描述需求的功能和性能。
用例图是一种图形化的需求规格方法，它可以清晰地描述系统的功能和用户之间的交互。
数据流图是一种描述系统输入、处理和输出的方法，它能够明确系统的数据流和数据处理过程。
状态转换图是一种描述系统状态和状态转换的方法，它能够清晰地描述系统的状态变化和状态转移。
需求验证是对需求的正确性和可行性进行验证的过程。
需求验证的方法有面谈、演示、原型测试和用例测试等。
面谈是需求验证的主要方法，通过与用户的交流和沟通，来验证需求的准确性和合理性。
演示可以通过模拟系统的功能和性能，来验证需求的可行性和有效性。
原型测试是通过制作系统的原型，来进行需求验证和改进的过程。
用例测试是通过编写测试用例和执行测试脚本，来对系统需求进行详细测试和验证。
如何进行有效的软件需求分析(五)
如何进行有效的软件需求分析导言：软件需求分析是软件开发过程中不可或缺的一环，它是确保软件开发项目顺利进行的关键步骤。
本文将介绍如何进行有效的软件需求分析，从需求获取、需求分析、需求规格化以及需求验证等方面进行论述。
一、需求获取需求获取是软件需求分析的第一步，它涉及与用户、业务专家和相关利益相关者的交流与沟通。
在需求获取阶段，可以采用以下几种常用的技术：1. 基于用户访谈：通过与用户面对面交流，了解用户真实需求，获取必要的功能和非功能需求。
2. 场景分析：通过场景模拟，让用户具体描述软件使用的环境和情景，从而更好地理解需求。
3. 问卷调查：通过设计问卷获取用户对软件的期望和需求，实现大规模需求获取。
4. 视频录制：将用户的操作场景录制下来，有助于后续的需求分析和理解。
二、需求分析需求分析是将需求进行整理和系统化的步骤，其目的是为了明确软件开发的目标和范围，将需求分解为可实现的任务和功能。
在需求分析阶段，我们可以采用以下方法：1. 需求分解：将整体需求分解为更小的、可执行的任务，确保每个需求都可以被正确地设计和实现。
2. 需求模型：使用统一建模语言（UML）等工具，将需求进行可视化建模，以便更好地理解和沟通需求。
3. 数据流图：通过绘制数据流图，清晰展示数据的流向和处理过程，更好地理解软件系统的功能需求。
4. 用例分析：通过用例图，描述用户在软件中的行为和交互，明确软件需求的功能性。
三、需求规格化需求规格化是将需求细化为具体的规格和指标，便于软件设计人员准确理解和实现。
以下是几种常见的需求规格化方法：1. 需求优先级划分：将需求按照其重要性和紧急性进行划分，明确开发的重点和阶段性目标。
2. 需求文档编写：使用规范化的需求文档格式，将需求以清晰明确的方式进行描述，确保不会出现二义性。
3. 用例描述：具体描述每个用例的执行步骤和预期结果，以供开发人员准确理解和实现。
四、需求验证需求验证是确认需求是否满足用户和业务需求的步骤，以确保软件开发过程中的正确性和可行性。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
需求获取与需求建模一．需求获取需求获取，属于软件工程中的一部分，包括需求来源和获取需求的技术。
它是软件设计的第一阶段，其本质主要是人的活动，涉及软件设计人员如何与客户建立有效的沟通。
也称为“需求发现”、“需求获得”。
需求获取(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中，用例表示为一个椭圆。
角色是指用户在系统中所扮演的角色。
其图形化的表示是一个小人。
在某些组织中很可能有许多角色实例（例如有很多个销售员），但就该系统而言，他们均起着同一种作用，扮演着相同的角色，所以用一个角色表示。
一个用户也可以扮演多种角色。
例如，一个高级营销人员既可以是贸易经理，也可以是普通的营销人员；一个营销人员也可以是售货员。
在处理角色时，应考虑其作用，而不是人或工作名称，这一点是很重要的。
我们使用不带箭头的线段将角色与用例连接到一起，表示两者之间交换信息，称之为通信联系。
角色触发用例，并与用例进行信息交换。
单个角色可与多个用例联系；反过来，一个用例可与多个角色联系。
对同一个用例而言，不同角色有着不同的作用：他们可以从用例中取值，也可以参与到用例中。
需要注意的是角色在用例图中是用类似人的图形来表示，尽管执行的，但角色未必是人。