软件需求复习资料.doc

bsp;维护
4业务建模（描述现实世界人与事物之间的相互关系）设计（实现手段、细节）分析（描述系统内部的核心机制，但不涉及具体手段）  业务建模（描述现实中的业务问题，不同人和不同部门之间协作关系）需求  （系统对外提供的功能和性能）
5用例定义了一组用例实例，其中每个用例都是系统所执行的一系列操作，这些操作生成特点主角可以观察的值。一个完整的用例定义有参与者、前置条件、场景、后置条件构成。捕获功能性需求就是用例的作用
6
7对于软件开发来说，业务建模的目的是描述现实，帮助发现需求。
8项目启动时要考虑的问题 愿景  涉众  投入  风险  可行  名称    (愿景描述项目的核心价值)
9愿景的两个要点？一定要来自老大的想法，一定要有度量指标。
10涉众包括： 1）最终用户，2）客户，3）开发人员，4）管理人员，5）竞争对手等
11对业务目标来说，规划手段可以是：取消一个业务目标;调整一个业务目标;
12对涉众的期望来说，规划手段可以是：取消一个涉众;减少一个涉众期望;调整一个涉众期望
13
14业务建模工作步骤选定业务单元 识别业务执行者  识别业务用例 详述业务用例 建立对象模型
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涉众经常来自当事人、上游、下游和操作对象的主人39
401、非功能性需求分几大类？答：可用性，可靠性，性能，可支持性2、用例之间有几种关系？答：扩展，包含，泛化
3、_______复用步骤的集合。  ________用于分离路径。答：包含，扩展
41需求调研方法:研究文档 问卷调查 访谈 观察 研究竞争对手 开会 制作示意板 角色扮演 原型开发  42系统顺序图优点图形化的交互 缺点:多此一举（不知不觉变成分析设计）使用不当会涉及内部结构
43系统状态图优点:消除歧义，适合小而关键的系统缺点：大系统画状态图不现实
44活动图优点：生动，便于交流缺点：精确性不够（数据需求、业务规则、非功能需求无法表达，还是要用文本来表示）主次路径不分（在用例图中，基本路径凸显该用例的核心价值）
45数据流图优点：第一种能逐步剖析大系统的方法 缺点：系统和外界责任模糊 只有0层数据流图（上下文图）才真正代表需求 更多关注系统内部的活动（分析） 其他设计元素已经可以取代（数据流图可被序列图取代）
46E-R图用数据关系来表达需求 优点：开发人员有基础，容易掌握 缺点：只能表达数据方面的需求 容易掌握不等于“重要” 稳定“不等于”真实、足够（相当于领域模型） 和涉众的交流问题（技术化）
47用户故事和用例的区别：用户故事的作用是备忘功能，而不是文档。而用例需要详细的描述其操作步骤，以及每个异常路径，因而起到了文档的作用
48类的泛化和关联的区别?泛化是集合关系而关联是个体关系
49识别类之间的关联。关联的几种表现形式：
50什么情况下可设置关联类。 两个类之间有多对多关系
51原型的分类 水平原型 垂直 静态 动态 低保真 高保真 废弃型 演化型
52需求评审的内容： 正确性 可度量 完整性 无歧义
53用例的要点 有意义的目标 执行者可见 业务语言，用户的观点
尽量不要用CRUD为用例，因为它们一般不提供价值，过于在乎细节，是从数据库角度进行考虑的。

活动图往往只表现事件，序列图表现责任分配和协作。需求不能复用，但设计可以复用。
54序列图中消息的方向代表责任不代表数据。业务对象模型（也称领域模型）是用类图描述用例中各概念间的关系。
55业务用例与系统用例的关系：多对多关系。
员工通过人事系统请假是否是人事系统的用例？不是
系统执行者与他是否重要无关。 系统用例的价值结果要由系统生成。 一个系统用例只有一个系统执行者。系统用例表示中，<后置条件：用例成功结束后系统应该具备的状态。  用例是涉众之间达成的契约，以执行者为达成特定目标和系统交互的方式演绎。用例平衡涉众之间的利益。
57寻找系统用例涉众的公安法：当事人，上游，下游，操作对象的主人。
58书写用例基本路径四部曲：动作、验证、改变和回应。
基本路径：凸显用例的核心价值。扩展路径：系统要处理的意外和分支。
非功能需求可分为可用性、可靠性、性能和可支持性。
59 1、平均10次操作能填写完一张申请单。（可用性）2、允许××人同时提交费用申请单。（性能）
3、软件应有中文和英文版本。（可支持性）
6061扩展分离扩展路径，包含提取公共步骤便于复用，泛化同一业务目的的不同实现。什么时候使用包含关系？某些步骤在多个用例中重复出现，且单独形成价值。  什么时候使用扩展关系？扩展路径步骤较多，扩展路径内部还有扩展点，扩展路径未定或容易变化，分离已冻结基用例
62需求不能杜撰，只能从涉众中来但是需求不能直接从涉众中来，它是需求分析人员综合所有涉众的需求写下的一份最后契约。   开专题研讨会，什么样的主持人最合适？中立人 对模糊、难定义的需求应采用哪种需求获取方法？原型法
63在场客户和用户故事是敏捷开发需求分析的两大特点。
从用例文档中识别出类和属性后还需对类图进行审查，审查可从哪些方面进行？
1属性是否直接描述类的特征2属性是否存在冗余3是否有复杂结构或1对多属性4属性是否对类的所有对象都有意义。
64类的泛化和关联关系的区别？1、泛化：子类通过继承拥有超类的特征（集合关系）。2、关联：对象通过组装拥有其他对象的特征（个体关系）。
65识别类之间的泛化有Liskov替换原则：子类型应该能替换掉基类型。
什么情况下可设置关联类。 两个类之间有多对多关系           识别类之间的关系
66水平原型用于功能需求的获取，垂直原型用于非功能需求的获取。
废弃型原型的目的是验证需求是否有错。  原型的性能等于系统的性能。错
需求的分层评审将需求分为目标性需求，功能性需求，操作性需求。
67需求变更管理的目标是控制变更，而非避免变更，减少变更对开发的影响。
实施需求变更管理的六大要旨：
1.建立需求基线，冻结需求。
2.制订简单、有效的变更控制流程，并形成文档。
3.成立项目变更控制委员会(CCB)或相关职能的类似组织，负责裁定接受哪些变更。
4.需求变更一定要先申请然后再评估，最后经过与变更大小相当级别的评审确认。
5.需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。
6.妥善保存变更产生的相关文档。