需求管理之知识点案例参考
案例1：
如果你是一个项目经理，你根据你所了解的软件生命周期模型，分析各个模型的优点、缺点以及适用的项目，总结一下对不同的项目所采取的生命周期模型，应如何选择?
可以根据项目的特点和需求来选择适合的生命周期模型。例如，如果项目需求稳定，开发周期长，风险较高，则可以选择瀑布模型；如果项目需求不稳定，需要快速迭代，则可以选择快速原型模型；如果项目需求变化较大，需要快速迭代，可以选择增量迭代模型；如果项目风险较大，需要强调风险评估，则可以选择螺旋模型；如果需要面向对象的软件开发过程，则可以选择喷泉模型
瀑布模型：
优点
1、各阶段文档齐全，减少沟通成本。
2、每个阶段评审通过才开始下一阶段，质量有保障。
缺点
1、不适应需求变更，如果变更之前所有阶段都必须调整。
2、每个阶段产生大量文档，管理困难。
3、用户不能很快看到软件产品
适用
适合用户需求无明显变化，无变动
快速原型模型：
优点
- 不带反馈环
- 本质是快速
- 基本线性顺序执行
- 用途是感知用户需求
- 减少较大返工
- 减少后续犯错可能
缺点
- 没考虑软件总体质量和长期可维护性
- 可能采用了不合适的操作系统，编程语言，低效的算法
- 开发过程不方便管理
适用
已有产品或产品的原型，只需客户化的工程项目增量迭代模型：
优点
- 优先实现基本和核心功能，提供用户评估平台
- 整个软件产品被分解成许多个增量构件，开发人员可以一个构件一个构件地逐步开发。
- 逐步增加产品功能可以使用户有较充裕的时间学习和适应新产品，从而减少一个全新的软件可能给客户组织带来的冲击。
- 多个构件并行开发，具有无法集成的风险
适用
慎重考虑使用渐进模型的情况
- 不能充分理解客户需求或客户需求有可能迅速发生变化
- 事先拟采用的技术迅速发生变化
- 客户突然提出一些新的功能需求
- 长时期内仅有有限的资源保证（开发人员和资金）
使用渐进模型的情况
- 需要在尽短的时间内得到系统基本功能的演示或使用
- 各版本都有中间阶段产品可提供使用
- 系统可以被自然地分割成渐增的模式
- 开发人员与资金可以逐步增加
螺旋模型：
优点
- 对可选方案和约束条件的强调有利于已有软件的重用，也有助于把软件质量作为软件开发的一个重要目标
- 减少了过多测试或测试不足
- 维护和开发之间并没有本质区别
缺点
- 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失
- 过多的迭代次数会增加开发成本，延迟提交时间
适用
内部大型软件系统
喷泉模型：
优点
- 支持面向对象模型，无缝迭代
- 该模型的各个阶段没有明显的界限，开发人员可以同步进行开发。其优点是可以提高软件项目开发效率，节省开发时间
缺点
由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理。此外这种模型要求严格管理文档，使得审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况
适用
适应于面向对象的软件开发过程。
案例2：
结合你所学的软件工程相关知识，请你表述一下结构化的开发方法与面向对象的开发方法思想的不同之处。
结构化开发方法和面向对象的开发方法是两种不同的软件开发方法。
结构化开发方法是一种基于模块化的软件开发方法，它将软件系统分解成多个模块，每个模块都有自己的输入、输出和处理逻辑。这种方法强调模块之间的接口和数据流，以及模块内部的结构和逻辑。结构化开发方法通常使用流程图、数据流图等工具来描述软件系统的结构和逻辑。
面向对象的开发方法则是一种基于对象的软件开发方法，它将软件系统看作由多个对象组成的集合。每个对象都有自己的属性和方法，可以与其他对象进行交互。这种方法强调对象之间的关系和交互，以及对象内部的状态和行为。面向对象的开发方法通常使用类图、时序图等工具来描述软件系统的结构和行为。
总之，结构化开发方法和面向对象的开发方法都是有效的软件开发方法。在选择软件开发方法时，需要根据项目需求和特点进行选择，并根据实际情况进行调整。
案例3：
小明刚入职，项目经理安排他参加需求的培训课程，培训老师了解到他是一名软件工程专业毕业的同学，就让他谈谈对软件需求的理解，软件需求工程主要的活动有哪些，具体完成哪些内容，需求工程有哪些特性？
软件需求是指对软件系统的功能、性能、质量、接口、设计约束等方面的描述。软件需求工程是软件工程的一个重要分支，它主要负责对软件需求进行分析、规格说明、验证和管理。
软件需求工程主要包括以下活动：
- 需求获取：收集和分析用户需求，确定软件系统的功能和性能要求。
- 需求分析：对用户需求进行分析和抽象，确定软件系统的功能和性能特性。
- 需求规格说明：将需求进行规范化描述，以便于后续的开发和测试。
- 需求验证：对需求进行验证，确保需求的正确性、完整性和一致性。
- 需求管理：对需求进行跟踪和管理，确保需求的变更得到及时处理。
在软件需求工程中，需求规格说明是一个非常重要的环节。它主要包括以下内容：
- 需求描述：对需求进行详细描述，包括功能、性能、质量、接口等方面。
- 需求分类：将需求进行分类，以便于后续的开发和测试。
- 需求优先级：确定各个需求的优先级，以便于后续的开发和测试。
- 需求追踪：对需求进行跟踪，以便于后续的开发和测试。
需求工程特性：
必要性
- 解决现实世界的问题：利用通用的计算机结构，构建一个有用的软件系统，来满足人们的某些目的
- 计算机应用于现实世界的广泛性
复杂性
- 处理范围广泛
- 涉及诸多参与方
- 处理内容多样
- 处理活动相互交织
- 处理结果要求严苛
软件需求：
- 用户解决某一问题或达到某一目标所需要实现的软件功能
- 系统或系统构建为了满足合同、规约、标准或其他正在实行的文档而必须满足或具备的软件功能
软件需求工程的主要活动：
需求开发
- 需求获取：从用户那里通过合适的方法获取需求
- 需求分析：需求的分类、建模与需求冲突的发现与解决
- 需求规格说明：需求文档化
- 需求验证：验证需求的正确性，保证需求以及文档的完整性和一致性
需求管理
在需求基线完成之后，跟踪后续阶段中的需求实现与需求变更情况，确保需求得到正确的理解和实现
需求工程特性：
必要性
- 解决现实世界的问题：利用通用的计算机结构，构建一个有用的软件系统，来满足人们的某些目的
- 计算机应用于现实世界的广泛性
复杂性
- 处理范围广泛
- 涉及诸多参与方
- 处理内容多样
- 处理活动相互交织
- 处理结果要求严苛
并发性
迭代性：需求分析模型复杂度会随和时间推移不断增加
案例4：
小李是一名软件需求工程师，刚刚参加工作，项目经理让小李谈一谈需求如何从业务问题转化为系统模型以及需要获取哪些需求？请结合案例从对需求的层次、每一层次的需求的含义和产出文档、不同层次间需求的关系以及需求的分类角度阐述。
需求从业务问题转化为系统模型的过程中，需求分析是关键。需求分析的目的是将业务需求和用户需求转化为产品的功能需求。在产品的需求中，经常有三个概念：业务需求、用户需求和功能需求。业务需求表示组织或客户高层次的目标，通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。用户需求描述的是用户的目标，或用户要求系统必须能完成的任务。功能需求规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。
产出文档为项目的前景和范围文档，用户文档（或称用例文档），需求规格说明文档
不同层次之间的关系
需求的分类
功能需求：
是和系统主要工作相关的需求，主要表现为系统和环境之间的行为交互
非功能需求：
性能需求：速度、容量、吞吐量、负载、实时性
质量属性：功能性、可靠性、可用性、效率、可维护性、可移植性
对外接口：与其他系统的软硬件接口和用户界面
约束：运行环境、相关标准、社会性因素、将来可能提出的需求
需求的层次
业务需求（目标）
- 来源于决策者
- 是系统的目标和效益
- 表现为解决方案与系统特性
- 描述为什么开发软件或系统why
- 形成的文档为项目的前景和范围文档
需求的层次
业务需求（目标）
- 来源于决策者
- 是系统的目标和效益
- 表现为解决方案与系统特性
- 描述为什么开发软件或系统why
- 形成的文档为项目的前景和范围文档
用户需求（任务）
- 来源于用户
- 是系统需要提供的具体任务
- 表现为问题域知识
- 描述用户使用系统能够做什么事情（what）
- 形成的文档为用户文档（或称用例文档）
系统需求（系统行为）
- 来自软件开发者
- 是软件系统行为
- 表现为系统分析模型
- 描述开发人员如何设计具体的解决方案来实现这些需求（how)
- 形成的文档为需求规格说明文档
不同层次之间的关系
需求的分类
功能需求：
是和系统主要工作相关的需求，主要表现为系统和环境之间的行为交互
非功能需求：
- 性能需求：速度、容量、吞吐量、负载、实时性
- 质量属性：功能性、可靠性、可用性、效率、可维护性、可移植性
- 对外接口：与其他系统的软硬件接口和用户界面
- 约束：运行环境、相关标准、社会性因素、将来可能提出的需求
案例5：
小王是一名需求工程师，在获取需求的过程中，她在与用户面谈的过程中，用户提出需要在系统功能的角度增加“月结算”的功能，同时系统的查询时间不多于1秒，系统应当能够存放1万条结算记录，系统可以允许100人同时在线工作。小王在面谈结束后，记录下了系统应添加的“月结算”功能，但是对于其他的内容认为不是系统的功能，不需要考虑到需求中，因此就没有写入用户的需求中。请结合需求的分类，谈一谈功能需求与非功能需求的含义和包含的具体内容，以及在软件系统中非功能需求的重要性。
在软件系统中，需求通常分为功能需求和非功能需求两类。功能需求描述了系统应该具备的功能，即系统应该能够完成哪些任务。例如，在这个案例中，用户提出的“月结算”功能就属于功能需求。
非功能需求描述了系统在运行时应该满足的一些性能、可靠性、安全性、可用性等方面的要求。例如，在这个案例中，用户提出的系统查询时间不多于1秒、系统应当能够存放1万条结算记录、系统可以允许100人同时在线工作等要求都属于非功能需求。
非功能需求在软件系统中同样重要，它们直接影响到系统的性能和用户体验。如果忽略了非功能需求，可能会导致系统在运行时出现性能瓶颈、安全漏洞等问题。因此，在获取需求的过程中，应当同时关注功能需求和非功能需求，并将它们都纳入到需求分析中。
功能需求
是和系统主要工作相关的需求，主要表现为系统和环境之间的行为交互
非功能需求
- 性能需求：速度、容量、吞吐量、负载、实时性
- 质量属性：功能性、可靠性、可用性、效率、可维护性、可移植性
- 对外接口：与其他系统的软硬件接口和用户界面
- 约束：运行环境、相关标准、社会性因素、将来可能提出的需求
案例6：
质量是软件的生命，这要从软件需求阶段就要体现出来，请结合质量属性谈一谈质量属性包括哪些方面，如何从用户那里获得对质量属性方面的需求呢？举例说明。
质量属性是指软件系统在运行时应该满足的一些性能、可靠性、安全性、可用性等方面的要求。这些要求通常属于非功能需求，它们直接影响到系统的性能和用户体验。
从用户那里获得对质量属性方面的需求，可以通过多种方式进行。例如，可以通过与用户面谈、问卷调查、用户观察等方式来了解用户对系统的期望。在与用户交流时，应当询问用户对系统的响应时间、容错能力、安全性等方面的要求，并将这些要求记录下来。
举个例子，假设我们正在开发一个网上购物系统。在与用户交流时，我们可以询问用户对网页加载速度、支付安全性、订单处理速度等方面的期望。例如，用户可能希望网页在3秒内加载完成，支付过程中能够保证信息安全，订单在24小时内处理完成等。我们需要将这些要求记录下来，并在后续的需求分析和系统设计中予以考虑。
质量属性包括
质量属性：功能性、可靠性、可用性、效率、可维护性、可移植性
如何获取质量属性方面需求
案例7：
项目经理安排小明完成一个项目的需求工作，小明应当如何完成一个完整的需求工程的过程以及如何衡量需求做的是否优秀呢？请结合需求工程的路线以及优秀的需求的特性谈一谈。
小明作为项目经理，他应当按照需求工程的流程来完成一个完整的需求工程。需求工程是一个不断反复的需求定义、文档记录、需求演进的过程，并最终在验证的基础上冻结需求。将需求工程分为六个阶段 (有不同的划分标准)： 需求获取 、 需求分析与协商 、 系统建模 、 需求规约 、 需求验证 以及 需求管理 六个阶段1。
衡量需求做的是否优秀，可以参考优秀的需求的特性，例如正确性、完整性和清晰性等。此外，还可以通过与用户的交流，对现有系统的观察及对任务进行分析，从而开发、捕获和修订用户的需求。
需求工程的过程
- 需求获取
- 选择信息的来源
- 定义项目前景和范围
- 选择获取方法、执行获取
- 记录获取结果
- 收取背景资料
- 需求分析
- 背景分析
- 确定系统边界
- 需求建模
- 确定优先级
- 需求协商
- 需求规格说明
- 业务需求被写入项目前景和范围文档
- 用户需求被写入用户文档
- 系统需求被写入需求规格说明
- 需求验证
- 执行验证
- 问题修正
- 需求管理
- 建立和维护需求基线集
- 建立需求跟踪信息
- 进行需求变更
需求工程的路线
问题分析和背景分析
需求获取
- 确定问题域范围
- 确定获取的源头、主题和内容，选择获取的方法
- 得到需求获取的文档资料
需求分析
- 建立系统模型
- 将用户需求转化为系统需求
文档化和验证
- 产生需求规格说明文档
- 对需求规格说明文档进行需求验证
优秀需求的特性
完整性：充分包括用户需求
正确性：真实反映用户需求
可行性：检查是否具备实现可能性
必要性：保证需求简介、不冗余
无歧义：定义词汇表，避免二义性
可验证：采用分析、检查、模拟或测试等方法验证需求是否被满足
案例8：
在实际的需求获取的过程，常常涉及到的范围和内容都是比较复杂的，结合所学的需求获取的非平凡性的相关知识，谈一谈为什么需求的获取过程是一个具有相当难度的活动？
需求获取过程是一个具有相当难度的活动，因为它涉及到的范围和内容都是比较复杂的。需求获取中的常见困难包括：用户和开发人员来自不同的环境，具有不同的背景和立场，有不同的表达方式和词汇集，因此他们之间必然会存在沟通障碍。
此外，需求与客户的期望和对现状的感知相关。客户对现状的感知可能会有所不同，这就增加了需求获取过程中的难度。
优秀需求的特性
完整性：充分包括用户需求
正确性：真实反映用户需求
可行性：检查是否具备实现可能性
必要性：保证需求简介、不冗余
无歧义：定义词汇表，避免二义性
可验证：采用分析、检查、模拟或测试等方法验证需求是否被满足
案例9：
需求工程师小王被安排完成需求获取的工作，他了解到需求获取就是从用户哪里获得系统具体要做什么，即具体的任务。结合需求获取的要点谈一谈小王在需求获取过程中需要考虑的要点以及每个要点中需要完成的相关内容？
需求获取是指在软件设计阶段，通过不同的形式和方法获取软件的业务性需求，可进行分析并转化为软件的功能性需求，提供给开发人员实现。需求获取的主要目标是理解用户需求，因而客户的参与是生产出优质软件的关键因素。
在需求获取过程中，小王需要考虑以下要点：
需求背景
需求调研
需求分析
其中，需求背景是指在对客户进行正式的需求调研前，要事前做好对客户的背景资料收集和整理，这是需求调研成功的基本保障。需求调研是指通过不同的形式和方法获取软件的业务性需求，可进行分析并转化为软件的功能性需求。
需求分析是指对已经收集到的需求进行分析和整理，以便于后续的开发工作。
需求获取过程(子活动)
- 研究应用背景，收集背景资料，建立初始的 知识框架；
- 获取问题，项目前景和范围文档
- 分析涉众，选择信息的来源
- 确定获取的内容和主题，建立系统边界，设 定场景；
- 根据获取的需要，采用必要的获取方法和技 巧；执行获取。分析用户的高（深）层目标， 理解用户的意图；
- 记录获取结果，写出 项目前景和范围文档。
要点
- 获取的内容
- 在项目的范围之内
- 所有为用户创建解决系统必须的信息：需求、问题域描述 、环境与约束
- 获取的内容不是一次得到的，而是逐步积累的
- 获取的来源：涉众、相关产品、硬数据、重要文档、相关技术标准和法规
- 确定需求获取的方法：传统方法、集体获取方法、原型、模型驱动方法、认知方法、基于上下文的方法、采样方法
- 获取的过程：防止需求遗漏、结束获取活动的判断条件
- 需求获取的结果：笔录，正式文档（项目前景和范围文档 、用例文档）
案例10：
需求工程师小王在需求获取的活动中需要找到项目的相关涉众并及进行涉众的分析工作。请给小王一些建议他该如何完成这个工作，即应考虑哪些涉众以及涉众分析的具体步骤。
涉众
1 用户: 最终使用和操作产品的人
关注软件功能，是需求信息来源
2 客户: 为软件系统的开发付费的人
关注经济上的成本、收益
3 开发者: 负责实现软件系统的人关注技术上的成本和收益
4.管理者：参与软件系统开发事务管理的人
投资方管理者 、执行负责人、项目管理者
关注系统的开发进程
5.领域专家: 在问题域中具有丰富知识的专家
关注软件中的知识6.政府力量 :法律法规 、长远规划、政策意向等
起约束和指导作用
7.市场力量：组织中的市场部门人员
关注用户的想法
8.维护人员：系统管理员，关注用户的想法人员
系统的日常维护涉众分析具体步骤
- 识别涉众
- 描述涉众
- 评估涉众
- 选择涉众
- 制定涉众代表参与需求开发（软件系统）的参与策略
案例11：
硬数据是需求工程师所获取的文档资料，需求工程师在需求获取的过程中，一般采用的硬数据类型有哪些？两种硬数据的形式和特点有哪些？
需求工程师在需求获取的过程中，一般采用的硬数据类型有两种：定量硬数据和定性硬数据。
定量硬数据是经过仔细设计、具有严格要求的格式化文档，如数据收集表格、统计报表等。
而定性的硬数据大都采用自然语言进行文本描述，利用起来代价较大，包括整个组织的描述文档、业务指导文档和业务备忘等
定量硬数据
- 数据收集表格
- 统计报表
- 数据收集表格
- 统计报表
定性硬数据
- 整个组织的描述文档
- 组织结构图 ：帮助发现项目的关键涉众
- 门户网站：反映组织的业务开展状况
- 业务指导文档
- 业务备忘
案例12：
项目经理让小张完成需求获取的过程，小张没有想好采取何种方式完成需求的获取以及需要获取的结果的形式。你能结合需求获取的方法和获取结果的形式给他一些建议吗？
需求获取的方法有很多种，包括观察法、体验法、单据分析法、报表分析法、问卷调查法、访谈法、需求调研会法等。对于需求获取结果的形式，可以采用图形、文字、表单等三种形式，这三种形式不但可以将客户现在企业的状况、问题、希望、需求等表达清楚，而且调研的结果还包含有非常清晰的逻辑性，要记住：调研结果不能只有“功能需求”、还必须有“逻辑需求”。
需求获取的方法
- 以用户的语言表达为关注点（传统方法）
- 传统方法：
- 问卷调查、面谈、硬数据分析、文档检查、需求剥离等
- 集体获取方法：
- 头脑风暴（Brainstorming）、专题讨论会（Workshop）、联合应用开发JAD、联合需求计划JRP等
- 原型：适用于需求模糊和不确定性较大的情况
- 模型驱动方法
- 定义明确的模型，确定所收集的信息类型，模型建立和完善的过程就是进行需求获取的过程
- 面向目标的方法、基于场景的方法、基于用例的方法
- 认知方法
- 以认知的方式获取用户无法表达的潜在知识
- 任务分析（Task Analysis）、协议分析（Protocol Analysis）等
2.注重用户在一定环境下表现出来的行为
- 基于上下文的方法
- 通过分析用户的行为得到信息：观察、民族志（Ethnography）和话语分析（Conversation Analysis）
- 采样方法：
- 随机采样
- 分层抽样
需求获取结果的形式
肯定会产生获取笔录
- 用户需求、问题域知识和约束
- 可能具有组织差、冗余、遗漏、自相矛盾等诸多问题
- 可以包括文字记录、录音、摄像等各种形式
可能会产生两份定义明确的正式文档
- 项目前景和范围文档
- 用例文档
案例13：
小李刚接手一个项目，项目经理分配小李完成项目前景和范围文档，他需要查阅相关资料了解前景和范围包括的内容、如何通过问题分析得到业务需求和解决方案与系统特性，以及前景和范围文档涉及到的人员、文档的结构。请回答他查阅资料以后得到的结果。
项目前景和范围文档是一种需求文档，其中“前景”描述了产品的作用和最终的功能，它将所有的涉众都统一到一个方向上；“范围”指出了当前项目是要解决产品长远规划的那一部分，它为项目规定了需求的界限。在这个文档中，你可以找到项目前景和范围包括的内容、如何通过问题分析得到业务需求和解决方案与系统特性，以及前景和范围文档涉及到的人员、文档的结构
案例14：
小李是一名软件需求工程师，刚刚参加工作，项目经理让小李安排一次与用户的面谈，请你给他一些建议，包括如何选择面谈的结构、如何选择面谈的类型、提出的问题的类型、记录面谈的方式、内容以及面谈结果的形式。。以下是一些建议：
面谈的结构：可以选择一对一的面谈或小组面谈。如果是小组面谈，可以考虑邀请多个用户参加，以便收集更多的意见和反馈。
面谈的类型：可以选择面对面的面谈或在线面谈。如果是在线面谈，可以使用视频会议工具，如Zoom、Teams等。
提出的问题的类型：可以提出开放性问题和封闭性问题。开放性问题可以帮助你了解用户的需求、期望和痛点，而封闭性问题可以帮助你收集具体的信息和数据。
记录面谈的方式：可以使用笔记本电脑、手机或纸质笔记本记录面谈内容。如果是在线面谈，可以使用视频会议工具自带的记录功能。
面谈内容：可以询问用户对产品的看法、需求、期望和痛点。你还可以询问他们对现有产品的使用情况、优点和缺点。
面谈结果的形式：可以将面谈结果整理成报告或幻灯片，并与项目经理和团队分享。你还可以将结果发送给用户以供他们审查
面谈的结构
- 金字塔型：话题逐渐式展开
- 漏斗型：开放式话题不断深入
- 菱形：逐步展开，话题深入
如何选择面谈的类型
- 结构化面谈：完全按照事先的问题和结构来控制面谈
- 半结构化面谈：实现根据面谈内容准备，在面谈过程中，会见者可以采取灵活的策略
- 非结构化面谈：没有事先预定的情况下就某个主题展开面谈
提出的问题的类型
- 开放式问题：适用于面谈前期，问题的回答一般是开放和不受限制的
- 封闭式问题：适用于面谈后期，问题的回答一般是受到限制的
记录面谈的方式
- 笔录
- 录音录像
面谈内容
- 事实和问题（主要）
- 被会见人的观点
- 被会见人的感受
- 组织和个人目标
案例15：
小王是一名需求工程师，在获取需求的过程中，他想用比较直观且快速的方式获取需求，他的同事建议他采取原型的方式。请给他一些建议，包括原型的含义，原型的类型、采取原型法的过程以及原型的风险。
同事建议小王采用原型的方式获取需求。以下是一些建议：
原型的含义：原型是一种快速、低成本的方法，可以帮助你快速验证和测试产品的想法和概念。它可以是一个简单的手绘图或一个高保真度的数字模型。
原型的类型：原型可以分为低保真度原型和高保真度原型。低保真度原型通常是手绘图或简单的数字模型，用于验证产品的基本功能和流程。高保真度原型通常是数字模型，用于验证产品的外观、交互和用户体验。
采取原型法的过程：采取原型法的过程包括以下步骤：
a. 确定需求：首先，你需要确定产品的需求和目标用户。
b. 设计原型：然后，你需要设计一个符合需求和用户期望的原型。
c. 测试原型：接下来，你需要测试原型并收集用户反馈。
d. 优化原型：最后，你需要根据用户反馈优化原型，并不断重复测试和优化过程。
原型的风险：使用原型法有一些风险，例如：
a. 花费时间和资源：制作高保真度原型需要花费大量时间和资源。
b. 误导用户：如果你没有正确设计和测试原型，它可能会误导用户并导致错误的决策。
c. 需求变更：如果需求在设计过程中发生变化，那么你可能需要重新设计和测试原型。
希望这些建议能够帮助小王采用原型法获取需求
采取原型法的过程
- 确定原型需求：为什么开发模型，拥有的起点时说明？期望的结束标准是什么
- 原型开发：依据原型的需求特点和开发目的，以最低成本建立初识原型
采取原型法的过程
- 确定原型需求：为什么开发模型，拥有的起点时说明？期望的结束标准是什么
- 原型开发：依据原型的需求特点和开发目的，以最低成本建立初识原型
原型的风险
- 最大的风险是成本失控
- 第二个风险是给用户造成错误印象，认为产品几乎已经完成，提出交付产品的需求
- 第三个风险是用户过多的关注原型的非功能特性，容易忽略功能特性
- 第四个风险是原型掩盖可能一些用户假设
案例16：
小明作为一名需求工程师，很了解需求分析在需求工程中的作用，因此，他通过建立需求分析模型来表达用户需求和系统需求，但是他不是很了解又哪些常用的需求分析技术。
请结合你所学的相关知识谈一谈
（1）你对需求分析的根本任务的理解、如何建立需求分析模型、常用的需求分析技术、这些技术的建模思想和具体的建模内容。
（2）需求分析的活动包括前期的需求分析活动和后期的需求分析活动，这两个活动都分别包括哪些内容？
需求分析的根本任务是确定系统的目标和范围，以及系统应该具备的功能和性能。建立需求分析模型通常包括数据流图、实体关系图和状态转换图等。常用的需求分析技术有数据流图、实体关系图、状态转换图、用例图和原型法等。这些技术的建模思想是通过对系统进行抽象和分解，来描述系统的功能和性能。
需求分析活动包括前期的需求获取和后期的需求验证。前期的需求获取包括需求调查、需求定义和需求规格说明书编写。后期的需求验证包括需求评审、原型验证和客户验收等。
案例17：结合所学谈一谈
（1）面向对象分析中五个层次以及具体所包含的内容。
（2）你对面向对象建模技术中的五大视图、四种（或者六种）关系在软件体系结构角度进行模型的思想的理解。
（3）UML建模过程中的三大类十种图有哪些？
（4）UML建模过程中所产生的模型和文档有哪些？
面向对象分析中五个层次包括需求分析、概念模型、分析模型、设计模型和实现模型。需求分析层次确定系统的目标和范围，概念模型层次描述系统的业务规则，分析模型层次描述系统的功能和性能，设计模型层次描述系统的结构和行为，实现模型层次描述系统的代码实现。
面向对象建模技术中的五大视图包括用例视图、逻辑视图、过程视图、组件视图和部署视图。四种关系包括关联、聚合、组合和继承。这些关系在软件体系结构角度进行模型的思想是通过对系统进行抽象和分解，来描述系统的结构和行为。
UML建模过程中的三大类十种图包括用例图、类图、对象图、状态图、活动图、序列图、协作图、组件图、部署图和包图。
UML建模过程中所产生的模型和文档包括需求规格说明书、概念模型文档、分析模型文档、设计模型文档和实现模型文档等。
面向对象分析中五个层次以及具体所包含的内容。
- 主题层：表示识别主题（子系统）活动，将性质相同的类与对象归纳为同一主题
- 类及对象层：识别类与对象
- 结构层（关系层）：识别结构（继承结构和组合结构）
- 属性层（有的叫特征层）：定义属性（包括实例）
- 服务层：定义服务（包括消息连接）
5大视图
- 用例视图（核心）
- 作用：描述系统的功能需求，找出用例和执行者
- 适用对象：客户、分析者、设计者、开发者和测试者
- 描述使用的图：用例图和活动图
- 重要性：系统的中心，它决定了其他视图的开发，用于确认和最终验证系统
- 逻辑视图
- 作用：描述如何实现系统内部的功能
- 适用对象：分析者、设计者、开发者
- 描述使用的图：类图和对象图、状态图、顺序图、合作图、活动图
- 重要性：描述了系统的静态结构和因发送消息而出现的动态协作关系
- 构件视图
- 作用：描述系统代码构件组织和实现模块，及它们之间的依赖关系
- 适用对象：设计者、开发者
- 描述使用的图：构件图
- 重要性：描述系统如何划分软件构件，如何进行编程
- 进程视图
- 作用：描述系统的并发性，并处理这些线程的通信和同步
- 适用对象：开发者和系统集成者
- 描述使用的图：状态图、顺序图、合作图、活动图、构件图和配置图
- 重要性：将系统分割成并发执行的控制线程及处理这些线程的通信和同步
- 配置视图
- 作用：描述系统的物理设备配置，如计算机、硬件设备以及它们相互间的连接
- 适用对象：开发者、系统集成者和测试者
- 描述使用的图：配置图
- 重要性：描述硬件设备的连接和哪个程序或对象驻留在哪台计算机上执行
4种关系
- 依赖：两个事物间的语义关系，其中一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义
- 两种依赖关系：包含依赖include，扩展依赖extend
- 关联：一种结构关系，连接模型元素及链接实例
- 实现：类元之间的语义关系，一个类元指定了由另一个类元保证执行的契约，如接口和实现它们的类或构件之间，用例和实现它们的协作之间
- 泛化：表示一般与特殊的关系，即一般元素是特殊关系的泛化
- 两种泛化关系：聚合，组合
三大类
- 用例模型图（功能模型）：用例图
- 静态模型图（对象模型）：类图、对象图、包图、构件图和配置图
- 动态模型图（行为模型，包括交互、状态模型）：由活动图、顺序图、状态图、合作图组成
十四种图
用例图、活动图、顺序图、状态图、合作图、类图、对象图、包图、构件图、配置图、新增四种（时间图、交互纵览图、组合结构图、外廓图）
9种模型
业务模型、领域模型、用例模型、分析模型、设计模型、进程模型、实现模型、配置模型、测试模型
2种文档
技术文档
- 需求分析信息集，包括软件规格说明书、需求补充说明、业务用例图等
- 设计信息集，包括软件设计规格说明书、图形界面、类图、对象图、包图、顺序图、状态图、合作图、活动图
- 实现信息集，包括源程序清单、动态链接库说明、用户适用手册、构件图
- 配置信息集，包括配置图及详细说明
管理文档，包括风险分析说明，软件开发进度计划，配置计划，测试计划，测试方案及步骤
案例18：
需求工程师小王被安排完成需求建模和编写用户文档的工作，他采用面向对象的建模方式，他需要了解用例建模的过程、用例模型中用例图包含的内容以及用例文档的组成。请根据你的所学为他提供相关知识。
用例建模的过程包括确定用例范围、识别参与者、识别用例、定义用例和编写用例文档等步骤。用例模型中用例图包含参与者、用例、关联关系和包含关系等内容。
用例文档的组成包括用例名称、参与者、前置条件、后置条件、基本流程和替代流程等内容。需求工程师小王可以根据这些知识完成需求建模和编写用户文档的工作。
用例建模的过程
- 定义系统
- 确定业务参与者(行为者）
- 确定用例
- 确定用例之间的关系
- 构建用例模型图（层次化用例图）
- 记录业务需求用例描述
- 检查（确认）用例模型：检查有没有单独的角色或用例，检查缺失和冗余
用例图包含的内容
主要元素：用例，参与者，依赖、类属、关联关系
可选元素：注释和约束，包，系统边界框用例文档的组成
用例名称：学生选课
执行者：学生
目的：完成一次学生选课的完整过程。
类型：主要的、基本的
级别：一级过程描述：
（1）学生输入标识码（ID），系统识别标识码的有效性；
（2）对学生进行注册识别；
（3）流览本学期预开课程；
（4）选择学生自己要上的课程并确认；
（5）退出系统，系统给出所选课程列表及相应学分合计。
案例19：
用例图中的依赖关系有两种情况，包含依赖和扩展依赖，请根据相关知识说明两种依赖应用于具有何种关系的用例之间，两种依赖的相同之处和不同之处有哪些？
包含依赖用于表示一个用例包含另一个用例的行为，即一个用例的执行依赖于另一个用例的执行。扩展依赖用于表示一个用例扩展另一个用例的行为，即在某些条件下，一个用例可以扩展另一个用例的行为。
两种依赖的相同之处在于都表示两个用例之间存在依赖关系。不同之处在于包含依赖表示一个用例必须执行另一个用例的行为，而扩展依赖表示一个用例可以选择性地扩展另一个用例的行为。
包含
- 方向：基本用例指向被包含用例
- 两个以上用例有大量一致的功能可以分解到一另一个用例中，其他用例和这个用例建立包含关系
- 被包含的是一种公共用例
- 执行基用例时必须执行被包含用例，被包含用例可以单独执行
扩展
- 方向""扩展用例指向被扩展用例（基本用例）
- 要在扩展点扩展，指明在原用例中的扩展位置
案例20：
需求工程师小王采用活动图绘制用例描述（或者用例规约），请结合所学谈一谈活动图中动作状态和活动状态的相同之处和不同之处。
活动图中的动作状态和活动状态都表示系统执行的操作。它们的相同之处在于都表示系统执行的操作。
不同之处在于动作状态表示一个原子操作，即一个不可分割的操作，而活动状态表示一个复合操作，即由多个子操作组成的操作。需求工程师小王可以根据这些知识绘制用例描述或用例规约。
案例21：
请结合实际谈一谈
（1）在用例建模过程中，用例的粒度所代表的含义以及如何采用一定的粒度对用例进行分层？
（2）对于复杂的项目，用例的粒度应当如何划分，需要考虑哪些问题？
用例的粒度代表用例描述的功能的抽象程度。采用一定的粒度对用例进行分层可以帮助我们更好地组织和管理用例。
对于复杂的项目，用例的粒度应当根据项目的实际情况进行划分。需要考虑的问题包括项目的规模、复杂度、参与者的数量和类型等。通常情况下，可以采用多层次的用例分层方法，将用例分为不同层次，每个层次的用例具有不同的粒度。