需求分析与设计笔记

1、软件生命:什么是成功的项目:在规定的时间内,在规定的成本要求下,达到或超过利益干系人的要求.软件开发战略性技术:项目管理:需求工程:软件架构软件开发的本质(不变性)：complexity:复杂性：conformity:一致性:changeability:可变性:invisibility:不可见性软件开发的偶然性因素：利益干系人l Boss、开发人员、客户、用户、竞争对手l 软硬件供应商、家人、政府：过程：建模只有确保过程的质量,才能保证结果的质量.SWOT:优劣势分析法软件三大类型:OLTP:在线事务处理：OLAP：在线分析系统：知识管理、AI、机器翻译生命周期：建模方法 ：阶段 ：开发技术和

2、方法软件开发技术/方法：面向功能（结构化：功能分解） ：面向对象（概念分解）：面向数据/信息 ：面向控制 ：面向服务需求工程：需求获取 ：分析：规格说明：确认：管理PM:项目管理（九大知识体系）PSM:技术管理软件成本估算：功能点估算法1：开发模式与项目特点相适应2：开发模式（好的PM/PSM至少掌握3种）与开发技术相适应软件需求:第一步是需求获取IT Solution:：业务解决方案，解决业务问题：业务过程的实现：实现业务创新本质没变，过程改变>针对过程改变:基础设施服务：是一种商品对传统业务方式通过互联网方式改造。需求获取：最困难 ：最关键 ：最易出错：最需要交流谁（需要的主体>

3、;最终用户） 需要 什么样(需求的形式呈现样式 布局颜色、操作方式) 的东西（需求的内容）需求的变更：其中问题60%由于开发人员的不专业（安隔间却拆楼）变更的种类：变更的频率由大至小变更影响由小至大：呈现样式：呈现内容：功能逻辑（算法）：功能间协作逻辑：数据模型（数据结构化）需求的种类:功能需求:非功能需求(质量属性+约束)定性不转定量 无法应用定性->定量：易用性 :复用性：灵活：性能：频率:可扩展性 ：安全性：可靠性（连续运行x小时）需求获取技术：传统技术：访谈（面谈）人少：会议（人多）：问卷：观察：文档研究获取的基础:是否具有领域知识(业务):沟通能力(社会学、生理学)访谈：访谈计

4、划 封闭性问题，用于确认开放性：访谈问题列表（有必要控制问题走向）（问题设计，决定访谈效果）针对不同角色：决策者（宏观 全局）执行者（中，局部）操作者（微观，细节）：时间（周一上周五下不好）：地点（办公单位不好）：小型会议室为佳，需放松：座位（考虑权势、威望、压迫感）：肢体语言：2个人 一说一记：调研报告问题信息应对软件开发有帮助例：学校是否有类似的学生信息管理系统若是->转向专业人士什么协议（TCP）数据类型如何获取、同步若否->学生具体信息为哪些是否可增加、如何增加需求获取1：访谈2:会议l 会议前的准备(计划、相关文档)l 会议中的过程控制(放跑题)u 设立会议主席、会议章程

5、u 1.5h内，保证效率l 会议后的总结3:问卷调查:封闭性问题 针对产品类 问题的设计很重要半封闭、开放性4：观察 信息量有限，有片面性、也直观5：文档研究l 国内外行业标准规范存在过时情况，理解易偏差l 行业相关技术规范l 企业业务流程工作手册，操作指南l 企业内部规章制度l 企业业务类报表，历史资料6：研究类似系统7：原型：抛弃型 ：进化型通过原型去将需求变稳妥，用少成本快速将双方需求达成共识。需求的层次：业务需求（目标需求）>目标：用户需求>用户期望系统实现的功能。：功能需求（功能需求）：技术需求开发软件系统先要理解业务，确立终极目标。需求分析：从业务用户需求(需求获取的内

6、容)得到功能、技术需求（软件开发人员分析）的过程。需求获取的风险与障碍（潜在的危险）若遇障碍，定性转定量，参考类似系统签合同前，多提可能，易提高佣金。对象：具有状态和行为边界的实体三要素：唯一标识：状态： 属性(与生俱来，内在固有)+特征值：行为：可测试、可见可衡量对象间的协作是通过消息传递来完成。n 显示的消息调用(P2P) 效率高n 隐式的消息调用(广播) 灵活性高类似于设计模式中的创建模式类：共享相同属性，操作，方法，关系或行为的一组对象的描述符。类之间的强弱顺序(耦合度)：依赖<关联<聚合<组合<继承类之间的静态联系称作关联：一对一、一对多、多对多概念模型是对现

7、实世界的映射表达方式：类图 、框图接口类型：1：系统间 2：模块间(组件间) 3：类间接口(公共方法)抽象：注重于对象的可观察行为封装：着重于引起这种行为的实现。为什么要创建用例模型：用例模型允许顾客和系统开发者之间用一种用户可以理解的语言交流系统要做什么：功能、技术。可以认为是一种顾客与系统开发者间的可视化契约(语言系统做什么、可视化、双方约定)。什么是用例模型：(使用人员)代表了从“最终用户角度”看到的系统的功能和环境。用例模型作用和意义：是从外部用户和外围系统的角度分析和考察待开发系统的行为并通过参与者(最终用户)与系统间的交互关系(用例)描述系统对外提供的功能特性。用例：(最终用户)使

8、用某个功能的应用场景。什么是用例：用例实例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。用例模型如何有效支持开发过程？用例模型得到的成果物：l 需求分析说明书l 用户手册的初稿l 测试用例的初稿创建用例模型的流程：确定系统范围，定义目标系统：识别参与者及其目标：捕获概要层用例，绘制初始用例图，确定大致的用例关系。：着重对系统的目标层用例进行细化。：针对每个用例详细说明。：分解、合并用例，精化用例模型结构。确定系统范围>系统的边界。通过创建待开发系统的 系统环境模型 中确定系统边界。系统间接口：通信协议(接口类型)：数据格式(数据内容)：数据获取（流向、主动和被动）：

9、数据同步方式人机接口：角色的特点为用户体验做准备。识别参与者：参与者是直接与用户交互的事务所扮演的(人、其他系统、硬件系统、时钟)角色如何识别参与者：谁或什么使用系统，交互中他们扮演什么角色：谁安装系统 谁启动和关闭系统 谁维护：与该系统交互的是其它什么系统，谁从系统获取信息谁提供信息给系统:有什么事情发生在固定时间。注意：参与者对系统而言都是外部的：参与者直接与系统交互：参与者表示的人和事物同系统发生交互时所扮演的 角色而不是特定的人或事物。：每个参与者需要一个具有业务意义的简短名称：每个参与者必须有简短描述，它从业务角度来描述参与者。用例建模（方法）>进行需求分析技术：面向对象技术。

10、需求分析：确定系统边界(创建系统环境)：识别参与者：识别用例>参与者与系统的一系列交互如何识别：特定参与者希望系统提供什么功能最终用户>用户需求：创建用例图命名规则：名+动用例>功能场景的集合功能的集合：用例规约详述模板：n 用例名称n 简要说明n 前置条件：对用例何时开始的约束，不是开始事件n 事件流(一系列交互)：用文本形式描述了用户与系统如何交互n 后置条件：无论执行哪些备选流，用例的后置条件应为真(无论何时都可回首页)事件流：基本流、备选流（异常、特殊）用例何时开始、用何种数据。用例中的动作类型：一般陈述句加以描述 主、谓、宾参与者：1：选择(界面、功能内容) 2：输

11、入（文本数据）系统:1：系统验证2：执行、处理3：输入（界面，内容 软件开发人员更易读文字，而不是流程图）准则：开发人员根据已描述流程，应可开发出相同产品(界面样式、布局操作)适应匹配：开发方法：面向对象开发模式：增量、迭代1：开发模式相适应2：用例先确定优先级（高 20%30% 中30%-40% 低 不低于40%）3:分清主次4：基本流/备选流WBS:任务分解1：应急成本(5-15%)提前验收期2：倒排计划3：工序调整4：加班 需计算加班时间，安排加班人、分类每日8小时 有效70%加班 1日 有效5：关键路径、人的安排6：细化用例模型 扩展关系扩展谁箭头指向谁包含关系：包含谁箭头指向谁包含/

12、扩展用例，不能单独执行考点：同：扩展与包含用例都是基本用例一部分：基本不执行，扩展与包含都不执行：扩展用例可扩展多个基本，包含用例可被多个用例包含。异：扩展关系基本用例基本流执行时，扩展用例不一定包含关系，基本用例基本流执行，包含用例一定执行。1212对单系统来讲，在需求上没差别1高复用性，可移入其他系统:用例建模的作用与意义：什么是用例模型：用例建模的流程：什么是用例：如何确定系统边界:如何识别参与者、用例：如何进行用例详述：扩展用例与包含用例、区别:用例模型包含内容（用例图、用例详述、活动图、主要原型、界面）概念模型：能映射到现实世界的真实事物帮助开发团队理解问题领域的各种概念，各种名词以

13、及它们之间的各种关系，描述系统的结构特征。创建概念模型的步骤：尽可能收集相关信息:识别概念l 名词/动词分析法n 找到备选类，从名词(短语)中提取对象与属性n 决定候选类n 确定类间关系n 为类添加职责(成员变量，方法)l 通用类模板l 用例驱动l CRCl 混合（1-4）：识别概念间关系：整合概念模型概念：实体类->持久化概念模型>数据模型ER图数据库逻辑模型概念模型：有符合现实世界的程度之分用例分析的目的：确定执行用例事件流的类，将每个用例情节都要落实到内部某个对象群体的协作上。用例建模：是对系统外在行为进行了解。用例分析的步骤：补充用例描述：针对每个用例识别分析类>对设

14、计类的抽象 从用例的事件流中查找分析类。：针对每个分析类确定它们的职责：整合分析类分析类：代表系统中具备职责与行为的事物的初期概念。分析类的种类：边界类： 负责系统与外界的通讯与交互、转换、翻译交互事件控制类：负责协调调度、处理事务并控制系统内部其它对象行为实体类：存储和管理系统中的信息(可持久化)边界接口类：1：用户接口、GUI2：系统接口3：设备接口：Timer每个用例都至少一个边界类控制类改进方案：1：将性质不同的控制逻辑封装到不同控制类2：将逻辑复杂的主时间流和备选流分别封装到不同的控制类中3：尽量为每一个参与者定义单独的控制类。分析模型：静态（分析类图、类图）动态（时序、协作图）对象

15、间职责是通过对象间协作确定的总结：概念模型的目的：创建概念模型的步骤：通过名/动词创建概念模型的方法：用例分析的目的：用例分析步骤：分析类的种类、职责：分析模型的构成设计阶段的步骤：1：设计过程创建交互模型的过程>对象的角色>职责（具体行为）2:设计结果：创建设计类图>总结过程角色：职责：针对设计类均为单一职责操作：分析阶段（具体行为）方法:设计阶段（具体执行动作）老师：l 备课：n 查找资料n 写教案n .l 讲课l 考核设计子系统>细件包的语义：集合/容器 对外可见（公有类可见）类的语义：信息隐藏<封装 （属性、方法的执行过程）面向对象编程核心：面向接口编程软件生产：l 框架库(平台)l 组件库1：从已有项目中提炼2：开源项目收集3：购买成型l 类库1：库函数版本2；第三方类库3：固有用例模型：系统的外在行为参与者与系统的一系列交互分析模型：分析类为设计类的抽象内部视角：对象（分析类）交互过程（创建对象）模型：完成/实现外在行为设计模型(是对分析模型的精化/细化)内部视角对象（分析类）通过交互完成（实现）了外在行为