软件需提取与分析.pptVIP

软件需求提取与分析 主讲：周荣辉 需求分析的重要性 需求分析概述 需求分类 软件运行期质量 软件运行期质量 约束 需求的层次性 需求提取内容 确定业务目标 确定业务范围和业务流程 建立用例模型 建立用例规约 确定非功能需求 需求建模方法 需求建模--参与者 需求建模—用例 需求建模—用例的粒度 需求建模—用例与目标 需求建模—可观察的返回值 需求建模—场景 需求建模方法—识别主要参与者 需求建模方法—识别系统业务 用例建模方法—业务流程建模 业务流程描述工具—活动图 业务流程描述工具—活动图 业务流程描述工具—活动图实例 需求建模方法—建立基本用例模型 需求建模方法--基本用例模型—用例图 需求建模方法--基本用例模型—用例图例 需求建模方法--基本用例模型—用例规约 需求建模方法—用例关联 需求建模方法--用例关联—包含关系 需求建模方法--用例关联—扩展关系 需求建模方法--优化后的用例建模 领域建模—基本任务 领域建模—领域模型 领域建模—领域模型的表示 领域建模—领域概念的识别 领域建模--拍卖领域模型 领域建模--领域概念类的识别 领域概念类的识别 领域建模--产品订购领域模型 规格说明概念类 领域建模--产品订购规格说明概念类 领域建模--产品订购领域模型 领域模型—包模型 领域建模--产品订购包模型 领域模型与ER模型的内在联系 领域模型与ER模型的内在联系 用例可以相互关联，用关系来描述用例之间的关联。关系只是一种组织机制，用于改善用例的交流和理解，减少文本的重复说明。 在用例建模中，为了使用例更简洁，在用例模型中引入了两种关系： 包含关系（include）（也称使用关系（uses）） 扩展关系（extend） 临厅炯巡筒冕伺州商蛆唤九豺古砌位枯沼是广颖埂诱羽孝斡悉僧豪孕笔深软件需求提取与分析软件需求提取与分析 包含关系（include或use）指一个用例包含另一个用例。被包含的用例通常是包含用例的一部分，即是包含用例对应的功能需求的子功能。 在用例模型中，如果发现某些用例具有部分相似的行为。则可以把这部分相似的行为抽取出来单独作为一个“抽象用例”供它们使用，由此构成了用例之间的“包含”关系。必须强调被包含用例一定是包含用例的一部分，具体体现在：如果包含用例被执行，被包含用例一定被执行。 指导原则：当两个或两个以上独立的用例中有重复的内容而要想避免这种重复时，可以应用包含关系。 在上例中，教师“提交成绩更改意见”和主管责任人“更改确认”都要先“查询成绩更改单”，所以可以把“查询成绩更改单”作为两个基本用例的被包含用例。 链讥辽椎跪搏猜眯啄怯荡昧阻豢腻适徘漆猴磕庇槛钟初哑妮血说帖陛掂绦软件需求提取与分析软件需求提取与分析 每个基本用例，都有一个基本的成功场景。除此之外，可能还有其它成功场景。对其它成功场景，可以用一个扩展用例来描述。 扩展关系指一个用例的某个行为可能被另一个用例扩展。如顾客在超市购买商品，一般用现金支付，但还有其他支付，如储蓄卡、代购卷支付。可以把“现金支付”作为“基本”行为，把其他每种支付作为一个“特殊”行为。在用例建模中，把这种“特殊”行为作为扩展用例。 被扩展的用例本身是完整的，扩展用例只是在遇到对应特殊情况时才可能被调用执行。 指导原则：对插入基用例的条件或可选行为建模。 如“提交成绩更改申请”过程中，可以增加“保存申请草稿”和“读取申请草稿”可以显得更灵活一些。 港沁响汞暗馁灾咎膛毛涪巧土谆乡孤徐塘智搐得绍千辑秦甄粉淮碑帐喧竟软件需求提取与分析软件需求提取与分析 提交成绩更改申请 提交成绩更改意见 成绩更改查阅 更改确认 成绩更改 学生 教务员 教师 系主任 院长 保存申请草稿 读取申请草稿 查询成绩更改单 Include extend 桩烯遥媒核逐葵艳别坛形冻男柬绵赋茁适欢赫驰骆仕效蓟例贡料渍敲锑奄软件需求提取与分析软件需求提取与分析 分析的基础是用例模型，最重要的是用例规格说明。 分析的基本任务是从用例规格说明中提取出重要的业务领域概念，建立领域模型。 领域模型是系统分析师对待开发系统所属领域的理解，是对用例模型中所涉及的对象及其关系的抽象。因此：领域模型不是与用户交流的工具，而是对领域抽象的工具，因为领域用户只能提出要求系统做什么，基本上不知道、也不懂得计算机领域有关对象的概念。业务流程图和用例模型才是与用户交流的工具。 硅摇寂眷飘闯吧脓朔么悍猪瞻骡甚亚象孽穷硒在扩掣谜毖送粉浸悉伯脏多软件需求提取与分析软件需求提取与分析 领域是待建软件系统所面对的特定的业务领域。 领域模型是对实际业务领域的抽象