1、 需求分析的最后阶段步骤最后阶段：需求管理步骤：需求变更管理、基线管理、需求跟踪2、 软件需求的任务（解决问题）和层次任务：系统必须做什么层次：概要目标层次（业务需求）、用户目标层次（用户需求）、功能层次（功能需求、 非功能需求3、 需求工程的活动分类需求开发、需求管理4、 需求管理需求变更管理、基线管理、需求跟踪5、 用例图的作用获取需求、指导测试、在其它环节中起指导作用6、 用例是什么用例是参与者与系统的一次交互7、 用例之间的关系包含关系扩展关系泛化关系二、选择（10个）1、 软件需求的概念（挑不对的）（1） 用户解决问题或达到目标所需的条件或能力2） 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力3） —种反映上面（1）或（2）所描述的条件或能力的文档说明2、 功能性需求和非功能性需求都包扌舌什么？非功能性需求：定义产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求;设计或实现的约束条件及质量属性过程需求产品需求外部需求）功能性需求：定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满 足了业务需求3、 需求变更：需求变更原因-客户方：对信息系统的了解不够对业务需求表达不清对自身业务抽象程度不够对需求重视程度不够与开发人员配合不够业务范閑不断拓展业务流程不断变更管理模式不断创新需求变更原因一软件人员：沟通技巧不高需求工程技术不精需求人员知识储备不够不了解客户方的业务流程调研范閑不确定 需求不够细致、明确项目管理不规范需求描述存在歧义合同对客户方约束不够5、 需求开发的范围？需求获取需求分析编写规范需求验证6、 功能分析工具：用例图界面定义原型开发7、 参与者的辨别？在系统之外，透过系统边界与系统进行有意义交互的任何事物都是参与者.对于一般规模的软件系统，参与者不会太多，一般有这样几种类型的参与者: 与系统交互的用户与系统交互的外部系统与系统交互的外部硬件特别注意：有时候时间触发器也可以看成是参与者三、1、需求工程活动（需求开发需求管理）用图形描述2、 编写用例图时要注意哪些因素？业务语言而非技术语言用户观点而非系统观点用例命名：动词+名词，尽量少用弱动词弱名词把步骤当用例避免使用CRUD一个用例背后可能隐藏很多数据操作3、 需求确认从哪几个方面进行一致性完整性可行性有效性一致性：所有需求需求必须是一致的，任何一条需求不能和其它需求相互矛盾。
完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能和性能首先要保 证系统的每一个目标都实现了可行性：需求中要求的硬件和软件技术必须是可实现的有效性：必须证明需求是正确有效的，确实能解决用户面对的问题4、 需求确认的主要方法审查需求文档根据需求编写测试用例编写用户手册确定合格的标准对一些需求模型采用形式化描述和验证5、用例之间包含关系和扩展关系的区别？包含关系:1.当在两个或多个独立用例重复自已并希塑避免重复时2. 在基本用例上插入附加行为并具有明确的描述3. 包含用例作为基本用例自身行为的一部分4. 包含关系是无条件的扩展关系：1.当表述关于正常行为的一个变化情况时2. 在基本用例上插入基本用例不能说明的扩展部分3. 扩展用例作为基本用例的增量扩展1. 扩展用例不是共用的用例2. 把可选行为从必须行为中分离出来3. 有条件地扩展已有用例的行为4. 基本用例可独立扩展用例单独存在5. 适合于功能需求的增加、设计原则）4. 扩展用例是按条件要求执行的1. 包含用例是共用的用例2. 一个基本用例可以有多个包含用例3. 一个包含用例可以包含在若干基本用例中4. 很难在包含关系上对系统进行维护修改。
6：用户界面定义应考虑的因素：（用户界面定义因素：界面元素、用户角色、需求变化、界面原型设计原则:简易性用户的语言记忆负担最小化 一致性利用用户的熟悉程度 从用户的观点考虑 排列分组安全性人性化7、对用例描述用例是从系统的外部对系统进行黑盒视图描述的一种组织方法 用例是抽象使用系统的一种方式，用户通过用例与系统交互 用例是参与者与系统的一次交互四、选课系统的用例图数据库。