需求工程-软件建模与分析
软件需求工程实验报告
软件需求工程实验报告软件需求工程实验报告摘要：本篇实验报告旨在介绍软件需求工程的基本概念、方法和实践过程。
通过对需求工程实验的设计和执行，我们深入了解了需求工程的重要性和应用价值。
本实验以一个虚拟的在线购物平台为例，通过需求分析、需求建模、需求验证等环节，详细描述了软件需求工程的实践过程，并总结了实验中遇到的问题和解决方案。
1. 引言软件需求工程是软件开发过程中至关重要的一环。
它旨在明确用户和系统之间的需求，为软件开发提供明确的目标和方向。
本实验以一个在线购物平台为例，通过需求工程的实践过程，展示了如何从用户需求到系统需求的转化过程。
2. 需求分析需求分析是软件需求工程的第一步。
通过与用户的沟通和交流，我们了解到用户对于在线购物平台的期望和需求。
在需求分析阶段，我们采用了面谈、问卷调查等方法，收集了用户的意见和建议。
通过分析用户需求，我们确定了在线购物平台的基本功能和特性。
3. 需求建模需求建模是将用户需求转化为系统需求的过程。
在本实验中，我们采用了用例图、活动图和类图等建模工具，对在线购物平台的功能和流程进行了详细描述。
通过用例图，我们清晰地展示了用户和系统之间的交互关系。
通过活动图，我们详细描述了用户在购物平台上的操作流程。
通过类图，我们定义了系统中各个对象的属性和行为。
4. 需求验证需求验证是确保需求的正确性和完整性的过程。
在本实验中，我们通过模拟用户操作和系统响应，验证了在线购物平台的功能和性能。
我们对系统进行了功能测试、性能测试和用户体验测试等，确保系统能够满足用户的需求和期望。
通过需求验证，我们发现了一些问题和不足，并及时进行了修正和改进。
5. 实验总结通过本次实验，我们深入了解了软件需求工程的实践过程和方法。
通过需求分析、需求建模和需求验证等环节，我们成功地将用户需求转化为系统需求，并验证了系统的功能和性能。
在实验过程中，我们也遇到了一些问题和挑战，但通过团队合作和不断努力，我们最终解决了这些问题，并取得了令人满意的结果。
软件工程中的软件需求建模与验证
软件工程中的软件需求建模与验证在软件工程领域中，软件需求建模与验证是非常重要的环节。
通过对软件需求的建模与验证，可以帮助开发团队实现对用户需求的准确理解，规避项目风险，提高软件质量。
本文将对软件需求建模与验证进行探讨，介绍其意义、常用方法以及实施过程中需要注意的事项。
一、软件需求建模的意义软件需求建模是指将用户需求转化为易于理解、易于分析的建模表示形式的过程。
它的意义主要体现在以下几个方面：1. 精确理解用户需求：用户需求通常是非结构化的，通过建模可以将其转化为结构化的表示形式，从而更好地理解用户需求的具体内容。
2. 消除需求的二义性：在软件开发过程中，需求二义性可能导致开发人员对用户需求理解存在偏差，从而产生错误的设计。
通过建模，可以减少需求的二义性，确保需求准确无误。
3. 支持复杂系统的设计与开发：对于复杂的软件系统，建模可以帮助开发人员更好地理解系统的结构与功能，从而更好地进行系统设计与开发。
二、软件需求建模方法在软件需求建模中，常用的方法包括数据流图、用例图等。
1. 数据流图（DFD）：数据流图是一种图形化表示方法，通过展示系统内部外部的数据流与处理过程来描述软件系统的功能与数据交互。
在数据流图中，数据流由数据流向箭头表示，处理过程由方框表示，外部实体由圆形表示。
2. 用例图（Use Case Diagram）：用例图是一种图形化表示方法，用于描述系统与外部实体之间的交互关系。
在用例图中，系统由矩形表示，外部实体由椭圆形表示，用例由椭圆形与直线表示。
三、软件需求验证的方法软件需求验证是指通过一系列的过程与活动，确保软件需求的正确性与合理性。
常用的软件需求验证方法包括软件检查、测试、原型等。
1. 软件检查：软件检查是通过审查软件需求文档，以发现并纠正其中的错误、遗漏和不一致之处。
软件检查可以由项目团队内部成员进行，也可以由外部的专业人士进行。
2. 软件测试：软件测试是通过执行各种测试用例，以发现软件需求与实际软件系统之间的差异，并对其进行评估。
软件需求工程中的模型及分析方法
软件需求工程中的模型及分析方法在软件开发中，软件需求工程是非常重要的一环，因为在这个阶段确定的需求将直接影响后续的软件设计和开发。
而模型及分析方法是软件需求工程的重要工具，它们可以帮助开发人员深入了解用户需求，更好地完成软件开发任务。
本文将围绕软件需求工程中的模型及分析方法展开讨论。
一、模型及其类型模型是对实际系统或过程的一种抽象表示，它可以帮助开发人员更好地理解和分析软件需求，在需求工程中常用的模型包括以下几种：1.1 静态模型静态模型是对系统或过程中的元素及其关系的表示，它们的变化不随时间而定。
在需求工程中常用的静态模型包括数据流图、结构图、实体关系图等。
数据流图可以表示系统中的数据输入、输出以及数据处理过程，它可以帮助开发人员更好地理解数据流动的过程。
结构图可以表示系统中的模块和模块之间的关系，它可以帮助开发人员更好地理解模块之间的交互。
实体关系图可以表示系统中不同实体之间的关系，它可以帮助开发人员更好地理解实体之间的交互。
1.2 动态模型动态模型是对系统或过程中的操作及其变化的表示，它们的变化随时间而定。
在需求工程中常用的动态模型包括状态图、活动图、时序图等。
状态图可以表示系统中不同状态之间的转换，它可以帮助开发人员更好地理解系统状态的变化。
活动图可以表示系统中各种活动的执行过程，它可以帮助开发人员更好地理解系统中不同活动之间的关系。
时序图可以表示系统中事件之间的时间顺序，它可以帮助开发人员更好地理解系统中不同事件的执行顺序。
1.3 物理模型物理模型是对系统或过程中的物理组件及其关系的表示，它们通常与硬件和软件的配合使用。
在需求工程中常用的物理模型包括部署图、机房图等。
部署图可以表示不同硬件之间的连接和通信，它可以帮助开发人员更好地理解系统中不同硬件之间的配合。
机房图可以表示不同设备在机房内的位置和连接方式，它可以帮助开发人员更好地理解机房中各种设备的位置关系。
二、分析方法及其应用分析方法是针对需求进行深入分析的方法，通过分析可以更好地理解用户需求并确定需求的可行性。
软件需求分析建模
小结
在需求获取和分析过程中，要对问题进行 评估，对方案进行综合。在整个过程中，分 析师关注的焦点是“做什么”，而不是“怎 么做”，系统必须完成什么功能，会产生什 么数据，将定义什么界面，会遇到什么约束 等。
总之，在这一阶段主要经历集中在获取和 分析系统的逻辑功能上。不要把“用计算机 如何实现”这样的物理因素牵扯进来，影响 逻辑功能的分析。
需求获取－需求人员
谁参加需求？
角色
职责
需求分析员
客户与最终 用户
项目组
调查、分析用户的需求、定义产品需求、 撰写《用户需求规格说明书》
提供必要的需求信息；确认最终需求
参与需求评审
需求获取－功能
功能性需求
软件必须实现的软件功能
非功能性需求
系统的易用性、反应速度、容错性、健壮性等等质量属性
需求获取－非功能
需求捕获技术－用户访谈
访谈开始和结束
陈述访谈的目的，谈谈被访谈者关心的事。 讨论他们所熟悉的日常工作的过程。 怎样的变化将使你的工作更简单或更有效？暗
示被访谈者提出改进意见。 当列表中的所有领域都讨论过后，提出下面问
题： “还有什么问题我们没有讨论吗？”或是 “ 我们还需要讨论些别的内容吗？” 结束会谈时，简短的总结讨论过的问题，重点 指出会谈的要点，并说出你的理解。 最后，你必须感谢被访谈者参加这次访谈。
本系统对于用户的需求，在功能上可以进行扩展，能满 足各级财政业务上的需求。
本系统在数据库上可以进行移植，支持Oracle,Sybase等 数据库。
需求获取-功能实例
需求获取—参与者
•谁使用了系统的主要功能？ •谁来维护和管理系统使系统正常工作？
角色及其职责描•哪述些人对系统产生的结果感兴趣？
软件工程中的需求分析与建模
● 03
第3章 需求建模技术
需求建模概述
需求建模是软件工程中的一个重要环节，通过对需求 进行建模，可以更清晰地理解和定义系统需求。需求 建模的目的是为了准确地捕获用户需求，确保软件开 发过程中不会遗漏任何重要需求。同时，需求建模还 可以帮助团队更好地沟通和协作，提高项目的成功率。
用例建模
用例是描述系统功能的一种有效方式。通过用 例建模，可以清晰地定义系统的功能和用户与 系统之间的交互。用例图可以直观地展示系统 的功能和不同用户角色之间的交互关系。用例 描述则详细描述了每个用例的具体行为和步骤。
意度。
需求变更频繁
导致开发过程混乱
需求不明确
影响产品质量
沟通不畅
导致需求误解
面临的挑战
可能的改进方向
采用敏捷开发模式
迭代开发 持续集成 快速反馈
加强需求管理
建立需求数据库 制定明确需求文档 实施变更控制
提高沟通效率
定期沟通会议 使用协同工具 建立需求反馈渠道
展望未来
未来在软件工程领域，人工智能技术的发展将为需求 分析带来更多可能性，大数据技术的应用将提升需求 建模的精度，需求管理工具的不断创新将提高团队效 率。
测试
单元测试 集成测试
软件工程发展历程
软件工程的发展经历了多个阶段，从最初的混沌时期 到逐渐建立起规范的软件开发流程和方法。随着科技 的不断进步，软件工程也在不断演变和完善。
● 02
第二章 需求分析基础
需求分析概述
需求分析是软件工程中至关重要的一部分，它 涉及定义、识别和规范软件开发项目中的需求。 通过需求分析，可以确保开发团队在项目开始 阶段清晰了解客户的需求，明确目标和方向。 需要对需求进行系统性的分析，以确保最终的
软件工程需求工程基础知识
软件工程需求工程基础知识软件工程是一门综合性的学科，其中需求工程是软件开发过程中至关重要的一部分。
在软件工程领域，需求工程基础知识的掌握对于确保软件项目成功和满足用户需求至关重要。
本文将介绍软件工程需求工程的基础知识。
一、需求工程的定义和重要性需求工程是通过与相关利益相关方沟通、分析和建模，以及定义软件需要满足的功能和性能等客观和主观需求的过程。
在软件开发过程中，需求工程是确保软件项目成功和满足用户需求的关键环节。
需求工程的目标是建立正确、一致、可追溯和可验证的需求规格说明，以确保软件开发团队理解用户需求，并能将其转化为可实现的软件系统。
二、需求工程过程需求工程过程包括需求获取、需求分析、需求规格说明、需求验证和需求管理等阶段。
1. 需求获取：需求获取是通过与相关利益相关方进行沟通和交流，从不同角度了解用户需求的过程。
常用的需求获取技术包括访谈、问卷调查、观察等。
2. 需求分析：需求分析是对获取到的需求进行梳理和整理的过程。
通过需求分析，可以识别出需求之间的关联性、冲突以及优先级等。
3. 需求规格说明：需求规格说明是对需求进行详细描述和规范化的过程。
常见的需求规格说明技术包括用例图、用例描述、数据流图等。
4. 需求验证：需求验证是确保需求规格说明的正确性和完整性的过程。
在需求验证阶段，可以通过检查、测试、评审等方式验证需求是否满足系统性能和用户需求。
5. 需求管理：需求管理是对需求进行跟踪、变更控制和配置管理的过程。
通过需求管理，可以确保需求在软件开发生命周期内得到有效管理和控制。
三、需求工程的关键技术1. 需求建模：需求建模是用于描述和分析软件需求的技术。
常见的需求建模技术包括数据流图、用例图、类图等。
2. 需求跟踪：需求跟踪是通过定义需求和设计元素之间的关系，实现对需求变更的管理和控制。
需求跟踪能够帮助开发团队追踪需求实现的状态和进程。
3. 用户界面设计：用户界面设计是通过用户友好的界面来满足用户需求的过程。
需求工程-软件建模与分析
需求⼯程-软件建模与分析1 问题分析的主要步骤（五步）？(1) 在问题定义上达成共识；(2) 理解根本原因，分析问题背后的问题；(3) 确定相关⼈员和⽤户；(4) 定义解决⽅案的界限；(5) 确定加在解决⽅案上的约束。
2 鱼⾻图主要⽤于定性分析，帕累托图主要⽤于定量分析。
3 鱼⾻图、帕累托图构建的主要步骤？鱼⾻图A 选择问题⾸先选择⼀个具体的问题或者结果。
在选择问题时，要保证问题是专门的、定义严谨的、范围相对较⼩的（对于⼤范围的问题往往需要考虑将其分解成相对较⼩的问题），并且保证参与⼈员切实理解要分析的内容。
对问题定义产⽣出来的问题⼀般都应该进⾏⼀次独⽴的鱼⾻图分析。
B 头脑风暴就导致问题的可能原因进⾏头脑风暴。
将⼤家提出的意见记录下来，确认后贴到鱼⾻图上。
需要注意的是不要将原因和解决⽅案混为⼀谈。
在确定原因的分类前先进⾏头脑风暴（⼀个⼈提，⼤家批），不然思考问题的范围就会受到限制。
⽀持者需要引导和⿎励参与者参与其中。
C 确定问题类型对头脑风暴的结果进⾏整理，确定出主要的原因类型。
⼀般来说，划分出来的问题不要少于2类，不要超过6类（经验数值，仅供参考）。
经常使⽤的类型有：⼈、设备、材料、环境、⽅法、过程等。
将这些类型补充到鱼⾻图上。
D 分配原因将头脑风暴中得出的潜在原因放在鱼⾻图上，并且确保每⼀项原因都归于适当的类别中。
如果原因看起来可以放在多个类别中，就表⽰是多重原因造成的问题。
但如果多次出现多重原因，可能就以为着分类存在问题。
该阶段将形成最终的鱼⾻图E 分析根本原因对鱼⾻图中罗列出来的所有潜在原因进⾏分析。
分析出造成某⼀结果的最根本原因是什么？找出核⼼所在。
⽅法如下：通过参与者之间的公开讨论来分享看法和经验；寻找重复的原因，或者与特定类有关的原因的数量；使⽤检查表收集资料、制造流程图或者进⾏⽤户调查，通过帕累托分析法测试各种原因的相对强度；投票（真理多数情况下掌握在多数⼈⼿⾥）帕累托图在通过使⽤鱼⾻图完成问题原因的定性描述后。
软件工程软件需求分析
软件工程软件需求分析软件需求分析是软件工程的一个重要过程，它是软件开发的基础。
软件需求分析是在软件工程生命周期中的需求工程阶段进行的，旨在识别和详细描述待开发软件系统的功能、性能、接口、约束等需求。
本文将从软件需求分析的定义、目的、过程和相关方法等方面进行详细阐述。
一、软件需求分析的定义软件需求分析是指对于待开发软件系统的需求进行系统化和详细的分析，以便于理解用户需求和系统规范，并将之转化为可行的技术规范。
软件需求分析旨在为软件开发过程提供指导，确保开发出满足用户需求且具备高质量的软件系统。
二、软件需求分析的目的1.确定软件系统的功能：通过软件需求分析，可以明确软件系统应该具备的功能，以满足用户的需求。
2.确定软件系统的性能：软件需求分析还可以确定软件系统的性能要求，如响应速度、可靠性、扩展性等。
3.确定软件系统的接口：软件需求分析可以明确软件系统与其他系统、硬件或用户之间的接口要求。
4.确定软件系统的约束：软件需求分析可以识别软件系统的约束条件，如预算、时间、人力等。
5.为软件开发过程提供指导：通过对需求的详细分析，可以为软件开发过程提供指导，确保开发出满足用户需求的高质量软件系统。
三、软件需求分析的过程1.需求收集：需求收集是软件需求分析的起点，它包括与用户沟通、文档分析、现场观察等方法，旨在收集用户对软件系统的需求。
2.需求分析：需求分析是对收集到的需求进行整理、划分、概述的过程。
它包括需求分类、需求建模、需求验证等步骤。
3.需求规约：需求规约是将需求转化为可执行的技术规范的过程。
它包括需求描述、需求确认、需求文档编写等步骤。
4.需求追踪：需求追踪是确保软件系统开发过程中需求的一致性和完整性的过程，它包括需求跟踪、变更控制、配置管理等步骤。
四、软件需求分析的方法1.采访法：通过与用户进行面对面的交流，提问并记录用户需求。
采访法可以确保准确收集到用户的需求，但可能存在信息偏差的问题。
2.文档分析法：通过阅读相关文档，如需求文档、用户手册等，获取对软件系统需求的理解。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1 问题分析的主要步骤（五步）？(1) 在问题定义上达成共识；(2) 理解根本原因，分析问题背后的问题；(3) 确定相关人员和用户；(4) 定义解决方案的界限；(5) 确定加在解决方案上的约束。
2 鱼骨图主要用于定性分析，帕累托图主要用于定量分析。
3 鱼骨图、帕累托图构建的主要步骤？鱼骨图A 选择问题首先选择一个具体的问题或者结果。
在选择问题时，要保证问题是专门的、定义严谨的、范围相对较小的（对于大范围的问题往往需要考虑将其分解成相对较小的问题），并且保证参与人员切实理解要分析的内容。
对问题定义产生出来的问题一般都应该进行一次独立的鱼骨图分析。
B 头脑风暴就导致问题的可能原因进行头脑风暴。
将大家提出的意见记录下来，确认后贴到鱼骨图上。
需要注意的是不要将原因和解决方案混为一谈。
在确定原因的分类前先进行头脑风暴（一个人提，大家批），不然思考问题的范围就会受到限制。
支持者需要引导和鼓励参与者参与其中。
C 确定问题类型对头脑风暴的结果进行整理，确定出主要的原因类型。
一般来说，划分出来的问题不要少于2类，不要超过6类（经验数值，仅供参考）。
经常使用的类型有：人、设备、材料、环境、方法、过程等。
将这些类型补充到鱼骨图上。
D 分配原因将头脑风暴中得出的潜在原因放在鱼骨图上，并且确保每一项原因都归于适当的类别中。
如果原因看起来可以放在多个类别中，就表示是多重原因造成的问题。
但如果多次出现多重原因，可能就以为着分类存在问题。
该阶段将形成最终的鱼骨图E 分析根本原因对鱼骨图中罗列出来的所有潜在原因进行分析。
分析出造成某一结果的最根本原因是什么？找出核心所在。
方法如下：通过参与者之间的公开讨论来分享看法和经验；寻找重复的原因，或者与特定类有关的原因的数量；使用检查表收集资料、制造流程图或者进行用户调查，通过帕累托分析法测试各种原因的相对强度；投票（真理多数情况下掌握在多数人手里）帕累托图在通过使用鱼骨图完成问题原因的定性描述后。
仍然存在一个问题，就是根本原因的辨识需要有经验的决策者确定，或者根据人类固有经验（少数服从多数）确定。
更好地方法是能够开展定量分析。
帕累托分析可以帮助我们做出这样的定量分析。
帕累托分析应用就是根据鱼骨图分析的结果，通过收集相关统计资料，通过直方图的方式显示问题的相对频度或者大小高低等定量结果。
A 确定问题和相关原因利用鱼骨图的结果。
B 收集数据有针对性第收集数据。
例如上例中，我们可以抽取一些废品，分析这些废品产生的原因C 绘制直方图4 上下文图画法步骤？在绘制上下文关系图时应该采用以下步骤：1、首先用一个矩形表示系统，写上系统的名称，将整个系统看做一个黑盒子；2、然后找到该系统的所有Customer(客户)，考虑这些Customer会发起什么事件，这些事件会引发Worker(内部工作人员)的什么工作，将这些序列逐一表示出来；3、最后在看看系统的每个Worker还有没有一些主动发起的事件。
（Customer：也就是该主题域的客户，它处于该主题域的外部。
如，对于体检业务子系统而言，体检者显然就是一类客户，除此之外，客服中心、物资部门、财务部门的工作人员也是这个主题域的Customer。
Worker：也就是该主题域的工作人员，它处于该主题域的内部。
如，服务中心，体检科室，综合科的工作人员都是其Worker。
关键要点在于“针对本主题域”而言。
）5需求获取的主要活动研究应用背景，建立初始的知识框架；根据获取的需要，采用必要的获取方法和技巧；先行确定获取的内容和主题，设定场景；分析用户的高（深）层目标，理解用户的意图；进行涉众分析，针对涉众的特点开展工作。
6需求协商的几条法则的应用？差异问题协调法则：不同的业务层面（有时即使是相同业务层面）的用户对同样的概念或者流程有不同的认识和理解，会出现一些差异，在需求整理时应该将这些差异明确标识出来，并展示给用户高层管理人员，由他们来确定如何消除这些差异，并将这些情况记录。
消除变更问题协调法则：上面法则提到的问题，从消除变更的角度考虑仍然存在问题。
仅仅将差异标识并展示给高层并不能消除变更的可能，应该考虑这些差异形成背后的问题，应该从开发角度考虑如何消除这些差异，并提供给高层管理人员。
要有主动性需求协商时机法则：不要在需求冻结前开展需求协商工作。
需求协商应该在需求获取过程中不断开展，出现就考虑消除。
如果都等到冻结前，将所有矛盾集中体现对工作是非常不利的。
实例：W公司开发的信息系统到了需求冻结前夕，A建立拿出厚厚一本需求协商底稿，分为重点差异协调部分，一般差异协调部分，已协调差异列表。
结果用户高层非常不满，认为这些工作需要大量时间难以短期完成。
7需求获取的主要方法用户访谈用户调查文档分析原型法（情节串联板）模型驱动的方法8开放式话题与封闭式话题运用开放式话题优点：–让被会见者感到自在；–会见者可以收集被会见者使用的词汇，这能反应他的教育、价值标准、态度和信念；–提供丰富的细节；–对没采用的进一步的提问有启迪作用；–让被会见者更感兴趣；–容许更多的自发性；–会见者可以在没有太多准备的情况下进行面谈。
缺点：–提此类问题可能会产生太多不相干的细节；–面谈可能失控；–开放式的回答会花费大量的时间才能获得有用的信息量；–可能会使会见者看上去没有准备封闭式话题优点：–节省时间；–切中要点；–保持对面谈的控制；–快速探讨大范围问题；–得到贴切的数据缺点：–使得被会见者厌烦；–得不到丰富的细节；–出于上述原因，失去主要思想；–不能建立和面谈者的友好关系。
9用户访谈时问题组织的三种方式及特点？金字塔结构如果会见者认为被会见者需要对话题进行预热，可以采用金字塔结构，通过逐步的引导来使得被会见者打开话匣子。
如果会见者发现自己事先对事实的确认存在较大偏差或者被会见者看上去不情愿讨论这个话题，也可以采用金字塔结构。
当想结束讨论这个话题的时候，使用金字塔结构的提问顺序也是有用的。
漏斗结构漏斗结构为开始一场面谈提供了一种容易而轻松的途径。
当被会见者对这个话题有情绪，并且需要自由表达这些情绪的时候，需要采用漏斗型提问顺序。
或者在会见者事先对事实了解不多时，也应该采用漏斗结构的问题组织方式。
用这种方式组织面谈能得出很多的详细信息，以至于没有必要使用长序列的受限制问题和调查问题。
菱形结构使用菱形结构的主要优点是通过各种各样的问题保持被会见者的兴趣和注意力。
一旦掌握了如何在正确的时间问正确的问题，就可以多样地选择问题的顺序。
10市场调查和需求获取在访谈与调查顺序上有何不同?原因何在？一般来说，在开展市场调查时，由于很难深入接触到潜在的用户。
所以总是先调查，后访谈。
而在需求获取时，通常采用的策略是先访谈，后调查。
其实原因在于市场调查与需求获取有不同的应用背景。
一般市场调查通常用于验证潜在客户对产品的接受程度。
而需求获取的目标是要理解客户需要解决的问题。
也就是说需求获取时你往往还没有产品，信息不够充分，所以很难设计出有效的调查问卷。
11采用原型方法的三个目的？明确并完善需求原型作为一种需求工具，它是对部分系统的初步实现，因为我们尚没有很好地了解该系统。
研究设计选择方案原型作为一种设计工具，涉众可以用它研究不同的用户交互技术，优化系统易用性，并评估可能的技术方案。
发展为最终产品原型作为一种构造工具，是产品一个最初子集的完整功能实现。
12用例描述方法13需求关系的根本任务是什么？需求分析是软件需求中最核心的工作，需求建模是需求分析的主要手段。
需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么?”这个问题。
需求分析的任务还不是确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。
需求分析根本任务：建立分析模型，创建解决方案。
14需求分析任务中分解策略主要包含那几种？每种策略分别适合应用于那些系统的开发1）业务流程为主线的分解策略；业务流程为主线的分解策略是目前比较流行的方法，主要按照“业务”的角度考虑分解方法。
此方法特别适合联机事务处理系统、管理信息系统（MIS）。
目标系统-》主题域的分解依据是“目标决定范围”；主题域-》业务事件所做的是理清业务脉络；业务事件-》业务活动所做的是填充细节；业务活动-》业务步骤所做的是细化和确认工作。
2）程序结构为主线的分解策略；方法是需求分析最常用的分解方法。
当由于其过早进入程序结构，割裂了与问题域之间的联系，从而容易导致对问题域研究的不足，降低了需求的质量。
目前认为此种方法仅适合于问题域比较清晰，问题不算复杂的情况，例如工具软件、嵌入式系统等。
3）基于场景的分解策略；对于决策支持系统、面向用户的嵌入式系统等来说，决策场景、使用场景是主要的线索。
向上可以总结成一类相似的集合，再总结成一系列的关注点或者功能域，向下可以分解成具体的步骤或者操作任务。
4）基于数据的分解策略等。
上述分解策略都是从“业务”角度来组织。
但对于类似数据仓库之类的数据类项目，业务线索并不是十分明显，或者并不重要这是就需要以数据为主的分解策略。
其中主题域仍然与“业务流程为主的分解策略”类似。
而主题类是企业中的高层实体，主要由一组企业的逻辑数据类来表示，而企业的逻辑数据类在实现时又会对应于多个物理数据类。
15 需求分析中分解与提炼的比较？分解是一种自顶向下的方法，当按照任何一种线索进行分解时。
就会破坏其它线索的完整性。
例如，如果以“业务”为线索，就会发现数据需求分解后会出现相互交叠的情况，也就是在多个业务事件中都涉及相同的类。
此种情况出现时，可能会影响需求分析人员建立全面的理解，因此需要采用自底向上的方法进行提炼。
例如将每个业务事件中的类进行提炼，抽取出共性的部分，建立针对整个系统的全局领域模型。
16构建分析模型的目的？1将复杂的系统分解成为简单的部分以及它们之间的联系，确定本质特征2和用户达成对信息内容的共同理解3分析的活动主要包括识别、定义和结构化，它的目的是获取某个可以转换为知识的事物的信息17分析模型的建模方法？模型–“模型是对事物的抽象，帮助人们在创建一个事物之前可以有更好的理解”–集中关注问题的计算特性（数据、功能、规则等等）–“它是对系统进行思考和推理的一种方式。
建模的目标是建立系统的一个表示，这个表示以精确一致的方式描述系统，使得系统的使用更加容易”–建模方法•抽象•分解•投影抽象（Abstraction）–一方面要求人们只关注重要的信息，忽略次要的内容•通过强调本质的特征，就减少了问题的复杂性（例如学生模型）–另一方面也要求人们将认知保留在适当的层次，屏蔽更深层次的细节•在问题的各元素之间推断出更广泛和更普遍的关系，帮助人们寻找解决方案 分解（Decomposition / Partitioning）–“分而治之”•将单个复杂和难以理解的问题分解成多个相对更容易的子问题，并掌握各子问题之间的联系–分解的方案往往还能提供问题的解决思路投影（Projection）–多视点方法18实际的建模过程中要遵循的建模原则？在建模时，要注意考虑到计划之外的变化：设计要文档化，只有这样，才能使不熟悉的新手也可以有效地利用设计的方案。