软件需求复习资料
软件工程复习资料精选全文完整版
可编辑修改精选全文完整版一、单选题（共20题，40分）1、使用数据流图，并不断细化的需求获取方法是（）。
（2.0）A、简易的应用规格说明B、面向数据流自顶向下逐步求精C、访谈D、快速原型法正确答案： B2、Z语言是以（）为基础的形式化规格说明语言。
（2.0）A、微积分B、概率C、图形D、一阶谓词演算正确答案： D3、HIPO是指（2.0）A、层次输入处理输出图或表B、层次功能结构图C、功能结构图D、输入处理输出图或表正确答案： A4、高铁调用系统最适宜采用（）方法。
（2.0）A、有穷状态机B、 Petri网C、 Z语言D、一阶线性时态逻辑正确答案： B5、假设学生年龄的成绩输入范围为18-25，则根据等价类划分技术，下列划分正确的是（）。
（2.0）A、可划分为2个有效等价类，2个无效等价类B、可划分为1个有效等价类，2个无效等价类C、可划分为2个有效等价类，1个无效等价类D、可划分为1个有效等价类，1个无效等价类正确答案： B6、用于并发系统，解决定时问题的形式化方法是（）。
（2.0）A、 VDMB、 Z语言C、 Petri网D、一阶线性时态逻辑正确答案： C7、软件生命周期中所花费费用最多的阶段是（2.0）A、需求分析B、软件总体设计C、软件维护D、软件实现正确答案： C8、软件质量保证措施SQA不包括：（2.0）A、复审或评审B、软件测试C、程序正确性证明D、软件代码编写正确答案： D9、希望确定软件实现的功能是否与需求规格说明书一致，需进行()。
（2.0）A、单元测试B、有效性测试C、确认测试D、集成测试正确答案： C10、总体设计不包括：（2.0）A、体系结构设计B、数据库设计C、模块内算法设计D、逻辑数据结构设计正确答案： C11、关于类和对象的说法，正确的是（2.0）A、一个类只能有一个角色B、类的命名必须用动词C、类的所有对象都具有相同的属性和操作D、类是对象的实例，对象是类的抽象正确答案： C12、数据字典的基本功能是（2.0）A、数据库设计B、数据通信C、数据定义D、数据维护正确答案： C13、软件需求规格说明的内容不应该包括（2.0）A、主要功能B、算法的描述C、用户界面及其运行环境D、软件性能正确答案： B14、增量模型在添加新的模块时，有一个要求是（）（2.0）A、需要更多的测试B、有足够的开发人员C、软件体系结构开放D、各个模块都要进行评审正确答案： C15、在软件详细设计过程中不采用的工具是（2.0）A、判定表B、PDLC、程序流程图D、DFD正确答案： D16、软件测试方法中，黑盒测试方法和白盒测试方法是常用的方法，其中黑盒测试方法主要用于测试（2.0）A、结构合理性B、软件外部功能C、程序正确性D、程序内部逻辑正确答案： B17、耦合是模块之间的相对独立性的度量。
上海市考研软件工程复习资料软件需求工程与软件测试技术总结
上海市考研软件工程复习资料软件需求工程与软件测试技术总结上海市考研软件工程复习资料：软件需求工程与软件测试技术总结软件需求工程和软件测试技术是软件工程领域中至关重要的两个方面。
软件需求工程涉及对软件项目需求的分析、定义和管理，而软件测试技术则负责确保软件的质量和可靠性。
本文总结了上海市考研软件工程考试中与软件需求工程和软件测试技术相关的内容，旨在为考生提供复习资料。
第一部分：软件需求工程软件需求工程是软件开发过程中的关键环节，它涉及了对用户需求的分析和定义，以及软件功能和性能的规划。
以下是上海市考研软件工程考试中常见的软件需求工程知识点：1. 软件需求的分类软件需求可以分为功能需求和非功能需求两大类。
功能需求描述了软件需要具备的功能和行为，而非功能需求则描述了软件的可用性、性能等方面要求。
2. 需求获取与分析需求获取是指通过与用户、客户或领域专家交流，确定软件需求的过程。
需求分析则是对获取到的需求进行详细研究和分析，以确保需求的准确性和完整性。
3. 需求规格说明书需求规格说明书是对软件需求进行详细描述的文档，通常包括需求的功能描述、性能要求、接口规范等内容。
4. 需求变更管理在软件开发过程中，需求的变更是正常的现象。
需求变更管理涉及对需求变更的评估、分析和控制，以确保变更对软件开发过程的影响最小化。
5. 需求跟踪和验证需求跟踪是指对需求的变更和实现过程进行追踪和管理，以确保软件开发过程中的需求得到满足。
需求验证则是对已实现的软件系统进行测试和确认，以确保其符合用户需求。
第二部分：软件测试技术软件测试技术是确保软件质量的关键环节，它涉及了对软件系统进行验证和评估的过程。
以下是上海市考研软件工程考试中常见的软件测试技术知识点：1. 软件测试的目的和原则软件测试的目的是发现并纠正软件中的错误和缺陷。
软件测试的原则包括全面性、独立性、及早性、错误定位和可测性等。
2. 软件测试的级别和类型软件测试可以分为单元测试、集成测试、系统测试和验收测试等级别。
软件需求工程 期末复习资料
☆什么是软件需求工程？请说明软件需求工程中各阶段的主要任务。
p51 定义一般定义：指应用工程化的方法、技术和规格来开发和管理软件的需求。
需求工程的目标：获取高质量的软件需求。
与软件工程中传统的需求分析概念相比，需求工程突出了工程化的原则，强调以系统化、条理化、可重复化的方法和技术进行与软件需求相关的活动，从而有利于提高所有与软件需求相关的活动及其过程的可管理性，降低需求开发和管理的难度和成本。
其它定义：Alan.Davis：直到（但不包括）把软件分解为实际架构组建之前的所有活动，即软件设计之前的一切活动。
该定义虽然没有详细说明需求工程是什么，但其给出了需求工程的范围。
Lan K. Bray：对问题域及需求做调查研究和描述，设计满足那些需求的解系统的特性，并用文档给予说明。
这个定义明确指出了需求工程的任务就是获取、分析和表达软件的需求。
需求工程= 需求的开发活动+ 需求的管理活动2 各阶段主要任务需求获取阶段：获取用户的需求信息。
需求分析阶段：分析和综合已经收集到的需求信息。
需求建模阶段：根据待开发软件系统的需求利用某种建模方法建立该系统的逻辑模型。
需求定义阶段：根据用户需求编写出需求规格说明。
需求的形式化描述阶段：用严格的数学知识和符号来构造系统的需求模型。
需求验证阶段：检验软件需求规格说明。
需求管理阶段：开发人员在与提出更改的请求者协商的基础上，评估需求变更带来的潜在影响及可能的成本及费用，然后实施更改，一级有效的管理需求规格说明文档和跟踪更改需求的状态。
☆什么是软件需求？软件需求有哪些类型，并分别给出它们的定义。
p2软件需求的定义:A. Davis：软件需求是从软件外部能发现的，软件所具有的，满足于用户的特点、功能及属性等的集合。
I. Sommerville：需求是问题信息和系统行为、特性、设计和实现约束的描述的集合。
M. Jackson等：需求是客户希望在问题域内产生的效果。
IEEE软件工程标准：（1）用户解决问题或达到目标所需的条件或能力；（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。
软件需求分析考试资料
软件需求分析考试资料第一篇：软件需求分析考试资料1、需求分析的最终结果是需求规格说明书。
2、需求分析中开发人员要从用户那里解决的最重要的问题是让软件做什么。
3、需求规格说明书中的内容不应该包括对算法的详细过程的描述。
4、需求规格说明书的作用不应包括软件可行性研究的依据。
5、关于面向对象方法中消息的叙述，不正确的是操作系统不断向应用程序发送消息，但应用程序不能向操作系统发送消息。
6、面向对象技术中，对象是类的实例，对象有三种成分标识、属性、方法（或操作）7、软件需求分析阶段的工作，可以分成以下四个方面对问题的识别、分析与综合、制定规格说明以及需求分析评审。
8、软件需求规格说明书的内容不应该包括对算法的详细过程的描述。
9、产品特性可以称为质量属性，在众多质量属性，对于开发人员来说重要的属性有哪些？可维护性、可移植性、可重用性、可测试性10、求包括11个方面的内容，其中网络和操作系统的要求属于环境需求，如何隔离用户之间的数据属于安全保密需求，执行速度、相应时间及吞吐量属于性能需求，规定系统平均出错时间属于质量保证。
11、需求分析过程应该建立3中模型，他们分别是数据模型、功能模型、行为模型，以下几种图形中，数据流图（DFD）属于功能模型，实体-联系图（ERD）属于数据模型，状态转换图（STD）属于行为模型。
12、常用的需求分析方法有：面向数据流的结构化分析方法（SA），面向对象的分析的分析方法（OOA），下列(D)不是结构化分析方法的图形工具。
A 决策树B 数据流图C数据字典D快速原型13、软件开发中，原型是软件的一个早期可运行的版本，它反映最终系统的部分重要特性，其中，探索型和实验型用完可以丢弃，而进化型围绕原型修改、增加。
14、数据流图用于描述数据的处理过程。
15、DFD 的基本符号不包括下列哪种？（A）。
A 数据字典B 加工C 外部实体D 数据流E 数据存储文件16、DD的主要字典条目包括以下哪种（E）A 数据流B文件C 数据项D加工E以上都是17、常用的动态分析方法不包括以下哪种（B）A 状态迁移图B 层次方框图C 时序图D Petri网18、需求分析阶段的文档包括以下哪些（E）A 软件需求规格说明书B 数据要求说明书C 初步的用户手册D 修改、完善与确定开发实施计划E 以上都是19、需求验证应该从下述几个方面进行验证：（C）A 可靠性、可用性、易用性、重用性B 可维护性、可移植性、可重用性、可测试性C 一致性、现实性、完整性、有效性D 功能性、非功能性20、风险管理的要素包括哪些（D）A 风险评价B 风险避免C 风险控制D 以上都是21、下列描述中错误的是（D）A 每一个集成的需求变更必须能跟踪控制到一个经核准的变更请求。
软件需求复习题
软件需求复习题软件需求复习题随着科技的不断发展，软件已经渗透到我们生活的方方面面。
无论是在工作中还是日常生活中，我们都离不开各种各样的软件应用。
而这些软件的开发离不开软件需求的明确和准确。
那么，你对软件需求了解多少呢？下面就让我们来复习一下软件需求的相关知识吧。
一、什么是软件需求？软件需求是指对软件系统所期望的功能、性能、接口等方面的描述。
它是软件开发过程中的第一步，也是最重要的一步。
软件需求的明确和准确直接影响着软件系统的质量和用户的满意度。
二、软件需求的分类根据软件需求的性质和表达方式，可以将软件需求分为以下几类：1. 功能需求：描述软件系统应该具备的功能和行为。
例如，一个音乐播放器应该具有播放、暂停、停止等基本功能。
2. 非功能需求：描述软件系统的性能、安全、可靠性等方面的要求。
例如，一个电商网站的非功能需求可能包括页面加载速度、交易安全性等。
3. 接口需求：描述软件系统与外部环境的交互方式和规范。
例如，一个手机应用的接口需求可能包括与摄像头、传感器等硬件设备的交互。
4. 数据需求：描述软件系统对数据的处理和管理要求。
例如，一个学生管理系统的数据需求可能包括学生信息的录入、查询和统计等。
三、软件需求的获取和分析软件需求的获取和分析是软件开发过程中的关键环节。
常用的软件需求获取和分析方法包括：1. 需求访谈：与用户和相关人员面对面交流，了解他们的需求和期望。
2. 观察法：观察用户在实际使用软件时的行为和反馈，从中获取需求。
3. 文档分析：对现有的相关文档进行分析，提取其中的需求信息。
4. 原型法：通过制作软件原型，让用户直观地感受到软件的功能和界面，从而获取需求。
四、软件需求的规格说明软件需求的规格说明是将获取到的需求进行整理和详细描述的过程。
常用的软件需求规格说明方法包括：1. 自然语言：使用自然语言进行需求的描述和说明。
例如，“系统应该能够实现用户注册和登录功能”。
2. 用例：使用用例图和用例描述对需求进行规格说明。
软件需求工程考试复习资料：复习提纲.doc
第二章:描述1、需求的定义a用户为了解决问题和解释或达到某些目标所需要的条件能力b系统或系统部件为了满足合同，标准，规范或其他正式文档所规定的要求而需要具备的条件或能力c对a或b中的一个条件或一种能力的一种文档表述。
2、需求的内涵：问题域、解系统与共享现象a要解决问题，就需要改变现实中某些实体的状态，或者改变实体状态变化的演进顺序，使其达到期望的状态和理想的演进顺序。
这些实体与状态构成了问题解决的基本范围，称为该问题的问题域。
b软件系统通过影响问题域，能够帮助人们解决问题，称为解系统。
c共享现象:通过映射建立的共同知识，就是问题域中与解系统中的共享现象。
3、分类：类别有：功能需求，性能需求，质量需求，对外接口，约束4、功能需求的三个层次:5、需求工程的路线图问题分析：明确问题定义业务需求制定解决方案及系统特性-＞需求获取：用户需求，性能需求质量属性对外接口约束问题域特性-＞需求分析：系统需求系统模型-＞文档化与验证第四章：描述6、需求获取的困难用户和开发人员的背景不同，立场不同首先是知识理解的困难。
尽力去研究应用的背景，理解组织的状况，形成一个能够和用户进行有效沟通的粗略的知识框架默认(Tacit)知识现象利用有效的获取方法与技巧(角色扮演、观察等)来发现并获取默认知识普通用户缺乏概括性、综合性的表述能力普通用户的知识结构就相对局限于一些具体的业务细节善于表达具体业务的细节问题专家用户的知识结构因其渊博性而具有概括性和广泛性能够回答概括性和综合性的问题开发人员在与用户接触之前就先行确定获取的内容主题,然后设计具体的应用环境和场景条件，由用户根据细节业务的执行来描述问题、表达期望。
7、需求获取的流程第五章8、定义项目前景和范围的流程:描述9、问题分析：应用第六章：描述+应用10、涉众分析的流程11、涉众识别的方法12、涉众评估的内容13、涉众选择的策略第7——9章：描述+应用14、面谈的问题类型15、面谈的结构16、面谈的优缺点17、原型的各种特征分类18、原型的优缺点利用原型的好处有:及时、有力的响应用户需求的变化；减少返工；帮助控制不完整需求所带来的风险；可以将一个大的难以处理的开发过程细分成一些更小更容易处理的步骤;减少开发成本，提高经济效益;增加开发者之间的交流，帮助确定技术解决方案的可行性；有效的识别风险和解决风险，帮助进行风险管理;提高用户在软件开发中的参与程度。
软件需求分析复习资料
计算机系统本身是无用的
������ ������ ������ ������ ������ ������
软件开创了新的可能性
目录
首页
上页
下页
末页
软件需求包括三个不同的层次—业务需求、用户需求和 功能需求（非功能需求）
业务需求（ business requirement）反映了 组织机构或客户对系统、产品高层次的目标 要求
原型法
适合于开发方清楚 对于开发方要求较 在以往类似项目应 项目需求但用户方 高 用系统的基础上进 不清楚项目需求的 行少量修改得出一 情况 可运行系统
节省开销 无法满足个性化软 重用建好的领域模 件要求 型，获得新系统需 13 复旦大学计算机科学与工程系 软件工程课程 求
目录 首页 上页 下页 末页
复旦大学计算机科学与工程系 软件工程课程 31
目录
首页
上页
下页
末页
类图
当你考虑如何将问题域对象映射到系统对象， 并进一步细化每个类的属性和操作时，面向对 象技术可以方便需求开发到设计阶段的转换。 类图(class diagram)是用图形方式叙述面向对 象分析所确定的类以及它们之间的关系。 用统一建模语言（UML）的符号为化学制品跟 踪系统的一部分（你所假设的）绘制类图。
末页
业务需求
•业务需求是组织或客户对于系统的高层次目标要求，定义 了项目的远景和范围，即确定软件产品的发展方向、功能 范围、目标客户和价值来源。 •业务需求的内容
–业务：产品属于哪类业务范畴？应该完成什么功能？需要为什么
服务？ –客户：产品为谁服务？目标客户是谁？
软件需求复习资料
第1章1.需求开发可进一步细分为：获取、分析、规格说明和确认。
2.需求问题导致的主要后果是返工—重复做您认为早已做好的事情。
3.造成软件成本估算失败的最主要原因包括频繁变更需求、遗漏需求、未与用户充分沟通、需求的说明不精确，以及对需求的分析不透彻4.实现有效的需求工程过程。
减少开发后期以及整个维护过程中不必要的返工并可带来极大的回报。
第2章1.客户泛指直接或间接得益于产品的个人或组织。
2.很多组织把在需求文档上签字作为客户认可需求的标志，签字不仅仅是仪式，更重要的是建立需求协议的基线。
第3章1.需求分析包括对需求进行推敲和润色以保证所有的涉众人都能够理解需求，以及仔细检查找其中的错误、疏漏和其他缺陷。
2.分析包括将高层的需求分解成具体细节、创建开发原型，以及评估可行性和协商需求优先级。
3.需求验证可确保需求声明是正确的、具备了所需的质量属性，而且能够满足客户的需要。
第4章1.需求分析员是对项目涉众的需求进行收集、分析、记录和验证等职责的主要承担者。
第5章1.产品前景将所有涉众统一到一个方向上。
前景描述了产品用来干什么，它最终会是什么样子。
2.项目范围确定当前的项目要解决产品长远规划中哪一部分。
3.广度(breadth)指应用能完成哪些业务工作(即用例)。
而深度(depth)则说明将各项用例实现到何种程度。
4.前景与范围文档用于将业务需求收集整理到一个文档中，为后续的开发工作打好基础。
5.涉众是积极参与项目、受项目结果影响，或者能够影响项目结果的个人、团体或组织。
第6章1.开发人员开发的产品与客户期望获得的产品之间常常存在较大差距，即所谓的期望鸿沟。
第七章1.需求工程的核心任务是需求获取，即确定软件系统涉众的需要及限制条件的过程。
2.使用增量开发方法，把需求分解成低风险的更小的部分进行研究3.使用活动挂图(flipchart)来捕获以后再考虑的一些条目4.将客户的意见归类：业务需求用例或场景业务规则功能性需求质量属性外部接口需求数据定义解决思路5.用例是对用户目标或用户需要执行的业务工作的一般性描述；使用场景则是某个用例的一条特定路径。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1到底解决什么业务问题？-----------业务建模为了解决业务问题，所开发系统应提供什么功能和性能--------------------需求定义SRS 软件需求规约为了提供功能，系统内部有什么核心机制？------------------------分析为了满足性能，系统的核心机制如何用稳定的技术实现？-------------------设计2 UML提供的元素中，那些图描述结构？哪些图描述行为？类图、对象图、构件图、部署图描述结构，状态图、序列图、活动图、协作图描述行为3软件开发的工作流程业务建模需求分析设计编码测试维护4业务建模（描述现实世界人与事物之间的相互关系）设计（实现手段、细节）分析（描述系统内部的核心机制，但不涉及具体手段）业务建模（描述现实中的业务问题，不同人和不同部门之间协作关系）需求（系统对外提供的功能和性能）5用例定义了一组用例实例，其中每个用例都是系统所执行的一系列操作，这些操作生成特点主角可以观察的值。
一个完整的用例定义有参与者、前置条件、场景、后置条件构成。
捕获功能性需求就是用例的作用67对于软件开发来说，业务建模的目的是描述现实，帮助发现需求。
8项目启动时要考虑的问题愿景涉众投入风险可行名称(愿景描述项目的核心价值)9愿景的两个要点？一定要来自老大的想法，一定要有度量指标。
10涉众包括：1）最终用户，2）客户，3）开发人员，4）管理人员，5）竞争对手等11对业务目标来说，规划手段可以是：取消一个业务目标;调整一个业务目标;12对涉众的期望来说，规划手段可以是：取消一个涉众;减少一个涉众期望;调整一个涉众期望1314业务建模工作步骤选定业务单元识别业务执行者识别业务用例详述业务用例建立对象模型15业务单元是一个组织或人群，探索系统需求就是探索涉众利益的平衡点。
16业务执行者：在业务之外，与业务交互的任何组织17以医院为研究对象，是描述一下名词的性质：护士2 病人1 CT扫描仪3 医生2保安2 医院信息系统3 政府1病历 3 1. 业务执行者2.业务工人3.业务实体18业务流程就是业务用例；业务里发生的一切都是为业务执行者提供价值。
19以医院为研究对象，以下正确的图是：（用例）1病人◊挂号2、医生◊诊断3病人◊求诊4收费人员◊收费正确：3以挂号室为研究对象时1正确。
20对于软件开发来说，业务建模的目的是什么？描述现实，帮助发现软件需求。
UML业务建模用两个模型来描述现实：业务用例模型和业务对象模型业务执行者和业务工人的区别？一个在业务外部，一个在业务内部21用例实例是系统执行的一系列动作，这些动作将生成特定执行者可见的价值结果。
一个用例定义一组用例实例。
通俗的说，就是执行者使用系统达到某个目的。
22识别用例：有意义的目标。
业务语言而非技术语言。
用户观点而非系统观点。
23表示用例：用例命名为执行者的视角（状语）动词（+（定语）宾语）24用例命名：2慎用弱名动词：进行，使用，复制，数据，报表，表格，系统25下面哪些是用例？1、支持跨行业务×这是一个业务规则，限定业务的范围。
2、插入卡片×这是一个过程步骤，不是完整的目标。
3、输入密码×这是一个过程步骤，不是完整的目标。
4、选择服务×这是一个过程步骤，不是完整的目标。
5、取钱√这是一个有效的完整目标。
6、存钱√这是一个有效的完整目标。
7、挂失卡片√这是一个有效的完整目标。
8、交纳费用√这是一个有效的完整目标。
9、三次错误吞没卡片×这是一个业务规则，限定业务的范围26用例和功能的误区一个错误的理解认为用例就是功能的划分和描述。
虽然用例是捕获功能性需求的，但有一个前提条件，即这个功能性需求是从参与者的角度出发的，用例并不是功能。
功能是脱离使用者的愿望而存在的。
27尽量不要用CRUD为用例，因为它们一般不提供价值，过于在乎细节，是从数据库角度进行考虑的。
28用例模板：用例编号：用例名|执行者|前置条件|后置条件|涉众利益|基本路径|扩展|字段列表|非功能需求|设计约束|业务规则|待解决问题29业务序列图关于业务序列图：1不可参杂实施以后的想象2消息的方向代表责任不代表数据3消息的名字代表责任和目的31循序图消息的方向代表责任不代表数据。
数据流用虚线表示，可以不画。
循序图侧重描述责任如何在业务工人和业务实体之间转移。
画循序图的目的是从图中找改进点。
找改进点就是在找需求。
32需求步骤：识别系统执行者；识别系统用例；书写系统用例文档；通过关系整理用例；用例的排序和分包需求只有一个视角：涉众视角系统执行者：在系统之外，透过系统边界与系统进行有意义交互的任何事务。
有多少个执行者就有多少个接口33业务执行者和系统执行者业务范围和系统范围是不同的。
业务范围指这个项目所涉及的所有客户业务，这些业务有没有计算机系统参与都客观存在。
系统范围则是指软件将要实现的那些对应于业务功能的系统功能，从功能性需求来说系统范围是业务范围的一个子集。
在找业务执行者时必须抛开计算机系统，没有这些系统业务人员也客观存在。
注意：首要条件是完全彻底地搞清客户的业务。
34执行者：有意义的交互。
责任的边界。
执行者与重要无关，执行者必须直接与系统交互351、以什么样的系统为研究对象时，“登录”作为用例是合适的？登录组件或认证系统2、以什么样的系统为研究对象时，“输入密码”作为用例是合适的？密码组件或验证系统36 评判以下的用例命名：1、进行图像导入使用弱动词，改为导入图像2、处理业务使用弱动词和弱名词3、生成贷款记录使用弱动词，生成只是内部一个步骤37判断以下陈述的对错业务执行者一定是系统执行者×系统执行者一定是业务工人×系统执行者一定要和系统交互√系统执行者一定是系统的涉众×原因：系统执行者如果是人，就是涉众。
如果不是人，就不是涉众。
但系统背后的人是涉众。
系统的涉众一定是系统的执行者×38涉众经常来自当事人、上游、下游和操作对象的主人39401、非功能性需求分几大类？答：可用性，可靠性，性能，可支持性2、用例之间有几种关系？答：扩展，包含，泛化3、_______复用步骤的集合。
________用于分离路径。
答：包含，扩展41需求调研方法:研究文档问卷调查访谈观察研究竞争对手开会制作示意板角色扮演原型开发42系统顺序图优点图形化的交互缺点:多此一举（不知不觉变成分析设计）使用不当会涉及内部结构43系统状态图优点:消除歧义，适合小而关键的系统缺点：大系统画状态图不现实44活动图优点：生动，便于交流缺点：精确性不够（数据需求、业务规则、非功能需求无法表达，还是要用文本来表示）主次路径不分（在用例图中，基本路径凸显该用例的核心价值）45数据流图优点：第一种能逐步剖析大系统的方法缺点：系统和外界责任模糊只有0层数据流图（上下文图）才真正代表需求更多关注系统内部的活动（分析）其他设计元素已经可以取代（数据流图可被序列图取代）46E-R图用数据关系来表达需求优点：开发人员有基础，容易掌握缺点：只能表达数据方面的需求容易掌握不等于“重要”稳定“不等于”真实、足够（相当于领域模型）和涉众的交流问题（技术化）47用户故事和用例的区别：用户故事的作用是备忘功能，而不是文档。
而用例需要详细的描述其操作步骤，以及每个异常路径，因而起到了文档的作用48类的泛化和关联的区别?泛化是集合关系而关联是个体关系49识别类之间的关联。
关联的几种表现形式：50什么情况下可设置关联类。
两个类之间有多对多关系51原型的分类水平原型垂直静态动态低保真高保真废弃型演化型52需求评审的内容：正确性可度量完整性无歧义53用例的要点有意义的目标执行者可见业务语言，用户的观点尽量不要用CRUD为用例，因为它们一般不提供价值，过于在乎细节，是从数据库角度进行考虑的。
活动图往往只表现事件，序列图表现责任分配和协作。
需求不能复用，但设计可以复用。
54序列图中消息的方向代表责任不代表数据。
业务对象模型（也称领域模型）是用类图描述用例中各概念间的关系。
55业务用例与系统用例的关系：多对多关系。
员工通过人事系统请假是否是人事系统的用例？不是系统执行者与他是否重要无关。
系统用例的价值结果要由系统生成。
一个系统用例只有一个系统执行者。
系统用例表示中，<<include>>和<<extend>>的含义。
56有关用例的粒度，最常犯的错误是把步骤当成用例。
用例文档中的前置条件：开始用例前所必需的系统及其环境的状态。
后置条件：用例成功结束后系统应该具备的状态。
用例是涉众之间达成的契约，以执行者为达成特定目标和系统交互的方式演绎。
用例平衡涉众之间的利益。
57寻找系统用例涉众的公安法：当事人，上游，下游，操作对象的主人。
58书写用例基本路径四部曲：动作、验证、改变和回应。
基本路径：凸显用例的核心价值。
扩展路径：系统要处理的意外和分支。
非功能需求可分为可用性、可靠性、性能和可支持性。
591、平均10次操作能填写完一张申请单。
（可用性）2、允许××人同时提交费用申请单。
（性能）3、软件应有中文和英文版本。
（可支持性）6061扩展分离扩展路径，包含提取公共步骤便于复用，泛化同一业务目的的不同实现。
什么时候使用包含关系？某些步骤在多个用例中重复出现，且单独形成价值。
什么时候使用扩展关系？扩展路径步骤较多，扩展路径内部还有扩展点，扩展路径未定或容易变化，分离已冻结基用例62需求不能杜撰，只能从涉众中来但是需求不能直接从涉众中来，它是需求分析人员综合所有涉众的需求写下的一份最后契约。
开专题研讨会，什么样的主持人最合适？中立人对模糊、难定义的需求应采用哪种需求获取方法？原型法63在场客户和用户故事是敏捷开发需求分析的两大特点。
从用例文档中识别出类和属性后还需对类图进行审查，审查可从哪些方面进行？1属性是否直接描述类的特征2属性是否存在冗余3是否有复杂结构或1对多属性4属性是否对类的所有对象都有意义。
64类的泛化和关联关系的区别？1、泛化：子类通过继承拥有超类的特征（集合关系）。
2、关联：对象通过组装拥有其他对象的特征（个体关系）。
65识别类之间的泛化有Liskov替换原则：子类型应该能替换掉基类型。
什么情况下可设置关联类。
两个类之间有多对多关系识别类之间的关系66水平原型用于功能需求的获取，垂直原型用于非功能需求的获取。
废弃型原型的目的是验证需求是否有错。
原型的性能等于系统的性能。
错需求的分层评审将需求分为目标性需求，功能性需求，操作性需求。
67需求变更管理的目标是控制变更，而非避免变更，减少变更对开发的影响。
实施需求变更管理的六大要旨：1.建立需求基线，冻结需求。