需求分析与设计笔记

《需求分析与设计笔记》由会员分享，可在线阅读，更多相关《需求分析与设计笔记（30页珍藏版）》请在装配图网上搜索。

1、软件生命:运行/维护开发阶段L_售前工程师（技术代合同签订详细设计完毕系统验收软件报废表）什么是成功的项目：在规定的时间内，在规定的成本要求下，达到或 超过利益干系人的要求.软件开发战略性技术： ：项目管理 :需求工程 :软件架构软件开发的本质（不变性）：complexity:复杂性 ： conformity: 一 致性 :changeability :可变性 :invisibility:不可见性软件开发的偶然性因素： ：利益干系人 Boss、开发人员、客户、用户、竞争对于软硬件供应商、家人、政府 ：过程 ：建模只有确保过程的质量，才能保证结果的质量.SWOT:优劣势分析法Misson Sta

2、tenentObjectives Goalsq+e + elPoliciesStrategies _软件三大类型： ：OLTP:在线事务处理 ：OLAP：在线分析系统 ：知识管理、AI、机器翻译生命周期： ：建模方法：阶段 ：开发技术和方法软件开发技术/方法: ：面向功能（结构化：功能分解）：面向对象（概念分解）：面向数据/信息 ：面向控制：面向服务需求工程： ：需求获取 ：分析：规格说明：确认 ：管理PM:项目管理（九大知识体系）PSM:技术管理软件成本估算：功能点估算法1：开发模式与项目特点相适应2：开发模式（好的PM/PSM至少掌握3种）与开发技术相适应软件需求:第一步是需求获取IT S

3、olution: ：业务解决方案，解决业务问题 ：业务过程的实现 ：实现业务创新本质没变，过程改变 针对过程改变 ：基础设施服务 ：是一种商品对传统业务方式通过互联网方式改造。需求获取： ：最困难：最关键 ：最易出错：最需要交流谁（需要的主体 最终用户）需要 什么样（需求的形式呈现样式 布局颜色、操作方式） 的东西（需求的内容）需求的变更：其中问题60%由于开发人员的不专业（安隔间却拆楼）变更的种类：变更的频率由大至小变更影响由小至大：呈现样式 ：呈现内容 ：功能逻辑（算法） ：功能间协作逻辑 ：数据模型（数据结构化）需求的种类： ：功能需求：非功能需求（质量属性+约束）定性不转定量无法应用定

4、性- 定量：易用性：复用性：灵活：性能：频率：可扩展性 ：安全性 ：可靠性（连续运行x小时）需求获取技术：传统技术：访谈（面谈）人少 ：会议（人多）：问卷：观察：文档研究获取的基础： ：是否具有领域知识（业务） :沟通能力（社会学、生理学）访谈: ：访谈计划封闭性问题，用于确认开放性 ：访谈问题列表（有必要控制问题走向）（问题设计，决定访谈效果）针对不同角色：决策者（宏观 全局）执行者（中，局部）操作者（微观，细节） ：时间（周一上周五下不好） ：地点（办公单位不好）：小型会议室为佳，需放松 ：座位（考虑权势、威望、压迫感） ：肢体语言 ：2个人一说一记 ：调研报告问题信息应对软件开发有帮助例

5、：学校是否有类似的学生信息管理系统若是- 转向专业人士什么协议（TCP）数据类型如何获取、同步若否-学生具体信息为哪些是否可增加、如何增加需求获取1:访谈2:会议会议前的准备（计划、相关文档）会议中的过程控制（放跑题）设立会议主席、会议章程 1.5h内，保证效率会议后的总结3:问卷调查：封闭性问题 针对产品类问题的设计很重要半封闭、开放性4：观察信息量有限，有片面性、也直观5：文档研究国内外行业标准规范行业相关技术规范存在过时情企业业务流程工作手册，操作指南况，理解易偏企业内部规章制度企业业务类报表，历史资料6：研究类似系统7：原型：抛弃型：进化型通过原型去将需求变稳妥，用少成本快速将双方需求

6、达成共识。需求的层次: ：业务需求（目标需求） 目标 ：用户需求 用户期望系统实现的功能。 ：功能需求（功能需求） ：技术需求 开发软件系统先要理解业务，确立终极目标。需求分析：从业务用户需求（需求获取的内容）得到功能、技术需求 （软件开发人员分析）的过程。需求获取需求分析全部业务及部分用户全部业务需求需求尽可能得到全部用户需求技术规划书+需求调研报告原始需求需求获取的风险与障碍（潜在的危险）若遇障碍，定性转定量，参考类似系统签合同前，多提可能，易提高佣金。对象：具有状态和行为边界的实体三要素：唯一标识 ：状态：属性（与生俱来，内在固有）+特征值 ：行为：可测试、可见可衡量对象间的协作是通过消

7、息传递来完成。显示的消息调用（P2P） 效率高隐式的消息调用（广播） 灵活性高类似于设计模式中的创建模式类：共享相同属性，操作，方法，关系或行为的一组对象的描述符。类之间的强弱顺序（耦合度）：依赖关联聚合组合继承类之间的静态联系称作关联：一对一、一对多、多对多概念模型是对现实世界的映射表达方式：类图、框图接口类型：1：系统间 2模块间（组件间）3：类间接口（公共方法）抽象：注重于对象的可观察行为封装：着重于引起这种行为的实现。为什么要创建用例模型:用例模型允许顾客和系统开发者之间用一种用户可以理解的语言 交流系统要做什么：功能、技术。可以认为是一种顾客与系统开发者间的可视化契约（语言系统做 什

8、么、可视化、双方约定）。什么是用例模型：（使用人员）代表了从“最终用户角度”看到的系统的功能和环境。用例模型作用和意义：是从外部用户和外围系统的角度分析和考察待开发系统的行为并 通过参与者（最终用户）与系统间的交互关系（用例）描述系统对外提 供的功能特性。用例：（最终用户）使用某个功能的应用场景。什么是用例：用例实例是在系统中执行的一系列动作，这些动作将生 成特定参与者可见的价值结果。用例模型如何有效支持开发过程？实施模型（代码用例模型得到的成果物：需求分析说明书用户手册的初稿测试用例的初稿创建用例模型的流程： ：确定系统范围，定义目标系统 ：识别参与者及其目标 ：捕获概要层用例，绘制初始用例

9、图，确定大致的用例关系。 ：着重对系统的目标层用例进行细化。 ：针对每个用例详细说明。 ：分解、合并用例，精化用例模型结构。确定系统范围 系统的边界。通过创建待开发系统的系统环境模型中确定系统边界。系统间接口：通信协议（接口类型） ：数据格式（数据内容） ：数据获取（流向、主动和被动） ：数据同步方式人机接口：角色的特点为用户体验做准备。识别参与者：参与者是直接与用户交互的事务所扮演的（人、其他系统、硬件系统、时钟）角色如何识别参与者： ：谁或什么使用系统，交互中他们扮演什么角色 ：谁安装系统谁启动和关闭系统谁维护 ：与该系统交互的是其它什么系统，谁从系统获取信息谁提供信息给系统 :有什么事情

10、发生在固定时间。注意：参与者对系统而言都是外部的 ：参与者直接与系统交互 ：参与者表示的人和事物同系统发生交互时所扮演的角色而不是特定的人或事物。 ：每个参与者需要一个具有业务意义的简短名称 :每个参与者必须有简短描述，它从业务角度来描述参与者。用例建模（方法） 进行需求分析技术：面向对象技术。需求分析： ：确定系统边界（创建系统环境） ：识别参与者 ：识别用例 参与者与系统的一系列交互如何识别：特定参与者希望系统提供什么功能最终用户用户需求 ：创建用例图9触卷I命名规则：名+动 用例功能 场景的集合 功能的集合 ：用例规约详述 模板：用例名称简要说明前置条件：对用例何时开始的约束，不是开始事

11、件事件流（一系列交互）：用文本形式描述了用户与系统如何交 互后置条件：无论执行哪些备选流，用例的后置条件应为真（无 论何时都可回首页）事件流：基本流、备选流（异常、特殊）用例何时开始、用何种数据。用例中的动作类型：一般陈述句加以描述 主、谓、宾参与者：1：选择（界面、功能内容）：2输入（文本数据）系统：1 :系统验证2：执行、处理3：输入（界面，内容 软件开发人员更易读文字，而不是流程图）准则：开发人员根据已描述流程，应可开发出相同产品（界面样式、 布局操作）适应匹配：开发方法：面向对象开发模式：增量、迭代1:开发模式相适应2:用例先确定优先级（高20%30%中30%-40% 低不低于40%）

12、3:分清主次4：基本流/备选流WBS:任务分解收工应急开始1：应急成本（5-15% ）提前验收期2：倒排计划3：工序调整4：加班 需计算加班时间，安排加班人、分类每日8小时有效70%加班1日有效5：关键路径、人的安排6：细化用例模型扩展关系扩展用例基本用例扩展谁箭头指向谁包含关系：包含谁箭头指向谁包含/扩展用例，不能单独执行考点：P 八、：同： ：扩展与包含用例都是基本用例一部分 ：基本不执行，扩展与包含都不执行 ：扩展用例可扩展多个基本，包含用例可被多个用例包含。异：扩展关系基本用例基本流执行时，扩展用例不一定包含关系，基本用例基本流执行，包含用例一定执行。1212对单系统来讲，在需求上没差

13、别1高复用性，可移入其他系统 :用例建模的作用与意义 ：什么是用例模型 ：用例建模的流程 ：什么是用例 ：如何确定系统边界 :如何识别参与者、用例 ：如何进行用例详述 ：扩展用例与包含用例、区别 :用例模型包含内容（用例图、用例详述、活动图、主要原型、界面）概念模型：能映射到现实世界的真实事物帮助开发团队理解问题领域的各种概念，各种名词以及它们之间 的各种关系，描述系统的结构特征。创建概念模型的步骤： ：尽可能收集相关信息 ：识别概念名词/动词分析法找到备选类，从名词（短语）中提取对象与属性决定候选类确定类间关系为类添加职责（成员变量，方法）通用类模板用例驱动 CRC混合（1-4） ：识别概念

14、间关系 ：整合概念模型实体类- 持久化概念模型数据模型 一ER图数据库逻辑模型概念模型：有符合现实世界的程度之分用例分析的日的:确定执行用例事件流的类，将每个用例情节都要落实到内部某个对象群体的协作上。用例建模：是对系统外在行为进行了解。用例分析的步骤： ：补充用例描述 :针对每个用例识别分析类对设计类的抽象 从用例的事 件流中查找分析类。 ：针对每个分析类确定它们的职责 ：整合分析类分析类：代表系统中具备职责与行为的事物的初期概念。分析类的种类：边界类：的通讯与交互、转换、翻译交互事件负责系统与外界控制类:负责协调调度、处理事务并控制系统内部其它对象行为实体类:存储和管理系统中的信息（可持久

15、化）边界接口类：1:用户接口、GUI2:系统接口3：设备接口： Timer每个用例都至少一个边界类控制类改进方案：1：将性质不同的控制逻辑封装到不同控制类2：将逻辑复杂的主时间流和备选流分别封装到不同的控制类中3：尽量为每一个参与者定义单独的控制类。分析模型：静态（分析类图、类图）动态（时序、协作图）提交按钮对象间职责是通过对象间协作确定的g ho po no （） o老师1系统界 面新增学生界面钮 1生 1学生学学生信 息1总结： ：概念模型的日的 ：创建概念模型的步骤 ：通过名/动词创建概念模型的方法 ：用例分析的目的 ：用例分析步骤 ：分析类的种类、职责 ：分析模型的构成设计阶段的步骤：

16、1：设计过程创建交互模型的过程对象的角色 职责（具体行为）2:设计结果：创建设计类图 总结过程角色：职责：针对设计类均为单一职责操作：分析阶段（具体行为）方法：设计阶段（具体执行动作）老师: 备课：查找资料写教案讲课考核设计子系统 细件包的语义：集合/容器 对外可见（公有类可见）类的语义：信息隐藏 职责具体行为用例模型用例分析整含分析美详细设计的程度:1：根据命名规范确定类名2：简要说明所完成的功能3：确定完成的属性集合4：针对属性简要说明5：确定完整方法集合6：针对每个方法要做简要说明7：针对复杂方法通过流程将这一方法的算法与业务逻辑进行说明分析行为:用例分析活动把系统的行为分配给分析类，让分析类交互来完成系统的行为设计构件：用例设计活动把系统的行为分配给设计元素子系统设计活动把子系统的行为分配给内部设计元素类设计活动完成分解给每个类的行为软件行业：核心竞争力：技术服务效率