软件工程：理论、技术及实践 课件 第4、5章 理解需求、需求分析

第4章

理解需求本章学习目标1.了解有关需求的基本知识。2.掌握需求工程的主要活动及它们之间的关系。3.掌握需求获取主要方法。4.应用用例和场景对需求建模。5.应用用户故事地图建立项目需求。

需求工程1软件需求获取2用例和场景3用户故事地图40理解需求Brooks曾描述“构建一个软件系统最困难的部分是确定构建什么，其他部分工作不会像这部分工作一样，在出错之后会如此严重地影响随后实现的系统，并且以后修补竟会如此的困难。”4.1需求工程需求工程的介绍对软件工程师来说，理解项目的需求是什么是他们所面临的最困难的工作之一。很多时候客户也不确切知道自己需要的是什么。他们能够接受在软件开发过程中需求的不断变化：有些是由沟通引起的，有些是外部干预者强加的，还有一些是客户随着项目演进不断提高对系统需求的认识所导致的。需求工程（RequirementsEngineering，简称RE）不能清晰地解决上述所有问题，但是项目总要有一个起始点，可以把需求工程理解为解决上述问题的一个较为可靠的途径。4.1需求工程需求工程划分为五个独立的阶段：（1）需求获取阶段需求获取指通过与各利益相关者交流、观察现有系统以及对任务进行探讨，从而捕获、导出和不断修订用户的需求的过程。在需求获取阶段，可以确定的一些利益相关者有：最终用户、软件工程师、产品工程师、业务运行管理人员、产品管理人员、市场销售人员、支持和维护工程师等。4.1需求工程需求工程划分为五个独立的阶段：（1）需求获取阶段下列因素导致了导出需求的困难：①范围：系统的边界不清楚、或是客户（用户）说明中带有不必要的技术细节，混淆而不是澄清系统的整体目标。②理解：客户（用户）并不能完全确定需要什么。③易变：需求会随着时间发生变化。在给定有限资源情况下，客户或者用户可能提出过高的要求，利益相关者也可能提出了相互冲突的需求，并强调他们各自要求的重要性。需求工程师必须通过协商过程来调节这些冲突。4.1需求工程需求工程划分为五个独立的阶段：（2）需求分析阶段需求分析是通过前面阶段全面的需求获取后，对需求进行的整理、规范和分析，用以说明软件的功能、特征和信息等各个方面。该阶段的任务主要集中于得到一个精确的需求模型。4.1需求工程需求工程划分为五个独立的阶段：（3）需求定义阶段需求定义是指在对所要开发的产品达成共识后，形成一份需求的一致性定义，也就是需求规格说明。如：IEEE的需求规格说明书模板。4.1需求工程需求工程划分为五个独立的阶段：（4）需求确认阶段需求确认主要是就需求定义和利益相关者进行沟通，并获得利益相关者的认可。在需求确认阶段需要做到以下几点：①软件需求规格说明正确描述了预期的满足各方需求的系统能力和特征。②从系统需求、业务规则或其他来源中正确地推导出软件需求。③需求是完整的、高质量的。④需求的表述在所有地方都是一致的。⑤需求为继续进行产品设计和构造提供了充分的基础。⑥可以预先设计一些需求确认检查表来检查每项需求是否是有用的。4.1需求工程需求工程划分为五个独立的阶段：（5）需求跟踪和变更控制阶段需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，确保产品依据需求文档进行开发，建立与维护“需求——设计——编程——测试”等后续工作之间的一致性，确保所有工作成果符合用户需求。4.2软件需求获取需求提取是发现用户真实需要的过程，也称需求捕获。软件需求提取可以分成两个步骤：理解应用领域和建立商业过程模型。例如：开发一个移动终端的实验室监管系统可以使用UML中的用例（UseCase）图、用例描述、活动图等来对业务过程建模。4.2.1需求获取方式4.2软件需求获取软件需求的获取方式主要有以下几种：1.直接与用户访谈和组织会谈2.用户工作环境体验和资料采集3.潜在用户调查报告4.市场相关产品调研5.快速原型方法4.2软件需求获取我们对系统建立的初始理解可以开始于对项目所处应用领域的了解。利用术语表完成对该领域中应用技术词汇的列表解释。例如：建立一个智慧教室系统智慧教室（SmartClassroom）的研究始于欧洲。从2005年英国雷丁大学研究智慧教室的学生交互行为开始，针对智慧教室的研究正式进入大众的视野。4.2.2应用领域理解4.2软件需求获取智慧教室主要是指借助互联网技术、智能技术等构建起来的新型教室。智慧教室旨在为教学活动提供人性化、智能化的互动空间；通过物理空间与数字空间的结合，本地与远程的结合，改善人与学习环境的关系，在学习空间实现人与环境的自然交互，促进个性化学习、开放式学习和泛在学习。该类新型教室通过各类智能装备的辅助更好地呈现教学内容、便利获取多样化学习资源、促进在课堂上展开多重交互，实现情境感知与环境管理功能的自动调节。4.2.2应用领域理解4.2软件需求获取（1）提供图像识别系统，可以实现人脸考勤、用户行为分析、用户情感分析等。（2）提供物联设备系统，可以实时监控教室温度、湿度等环境变化，并自动做出调整；能够自动控制教室设备。（3）提供互动交互系统，通过智能录课将线下课堂与云课堂结合，支持云端回看，同时配有电子白板和电子书包等。现有的智慧教室的主要功能有：4.2软件需求获取表4-1智慧教室实例初始术语表术语解释考勤系统考勤系统是指一套管理出勤记录等相关情况的管理系统人脸考勤通过教室摄像头记录识别人脸信息完成考勤用户行为分析学生课堂情绪与行为的检测，包括对学生考勤、情绪、低头及交头接耳行为等进行识别物联教室实时监控教室温度、湿度等环境变化，并自动做出调整，能够自动控制教室设备智能录课自动录制课程并上传到云端供学生课后查看云课堂基于云计算技术的一种高效、便捷、实时互动的远程教学课堂形式电子白板显示上课内容，保存板书供学生课后学习电子书包利用信息化设备进行教学的便携式终端4.2软件需求获取图4-1智慧教室系统网络拓扑结构4.2.3应用实例需求获取智慧教室管理系统人脸考勤业务主要流程：（1）生物信息采集用智能终端采集人脸照片，并上传到后台系统中，由教师确认照片为学生本人无误后，交由后台识别软件识别生成人脸信息库。4.2软件需求获取4.2.3应用实例需求获取（2）考勤学生在教室就坐后，由教师提醒学生抬头，并向智慧教室终端发送签到指令，启动考勤服务。通过教室的摄像头采集教室里的学生图像，通过网络发送给云端服务软件进行识别，并将识别结果和人脸信息库中的信息进行匹配比对，若相似度大于设定的某个阈值，则考勤成功，反之则考勤失败，暂记作缺勤处理。在上课期间，考勤系统持续工作，抓拍学生人脸图像进行比对，对缺勤记录进行修正。下课前，由老师关闭考勤服务。（3）统计结果考勤后，统计应到学生数和实到学生数，并将对接的教务系统中请假的学生作标注，最终得到本次的考勤结果。4.2软件需求获取4.2.3应用实例需求获取（4）人脸考勤时的特殊情况①录入：录入时学生可能会误操作上传其他人脸的照片，所以需要教师确认照片是学生本人无误后再交由后台处理。②考勤：考勤时学生可能低着头未被摄像头采集到人脸信息，所以需要学生主动抬起头，或者在上课期间，多次补充人脸信息采集。③统计：可能存在学生请假，但未在教务系统上申请的情况，所以要提供可以修改考勤结果的途径。④可能还有其他的异常情况会产生，需要在多次沟通后逐步调整需求。用例图描述的是参与者所理解的系统功能，帮助人们以一种可视化的方式理解系统的功能需求，讲述了最终用户如何在一个特定环境下和系统交互。用例图有四个部分：用例（UseCase）、参与者（Actor）、系统边界、关系。（1）用例是参与者可以感受到的系统服务或功能单元。（2）参与者是与系统交互的人或物，是在将要说明的功能和行为环境内使用系统或产品的外部实体或角色。参与者可以是人、其他软件系统、硬件设备或其他与系统进行交互的实体。（3）系统边界指系统与系统之间的界限。把系统边界以外的同系统相关联的其他部分称为系统环境。4.3用例和场景4.3.1UML用例和场景4.3用例和场景4.3.1UML用例和场景（4）在用例图中表示的关系有四种：关联、泛化、包含和扩展。①关联关系图4-2用例图中的关联关系②泛化关系图4-3父用例和子用例的关系图4-4参与者之间存在泛化关系4.3用例和场景4.3.1UML用例和场景（4）在用例图中表示的关系有四种：关联、泛化、包含和扩展。③包含关系图4-5用例之间包含关系示意图④扩展关系图4-6用例之间扩展关系4.3用例和场景4.3.1UML用例和场景在用例图中，场景通常被定义为特定用例的一个或多个实例，用以描述系统如何与外部参与者交互以实现特定目标或功能。场景描述了参与者如何与系统交互，触发特定用例，以及系统对这些触发的响应。用例和场景之间的区别在于用例提供了整个功能的一般描述，而场景是用例的特定实例，就如对象是类的一个实例。场景的定义应简洁明了，利益相关者通过场景可以更好地理解系统的功能和行为。通过建立特定场景可以进一步提取需求。4.3.2应用实例业务模型业务模型是对商业过程的描述，可以通过访谈，结合调查问卷、检查业务上使用的各种表格以及对用户直接观察等方法来获取业务模型信息。4.3用例和场景4.3.2应用实例业务模型（1）初始系统用例智慧教室的人脸考勤业务模型概述为：学生在智慧教室后端上传学生人脸照片，并由教师审核通过后存入人脸信息库。上课时，教师通过智慧教室终端发送考勤指令，教室摄像头采集学生人脸信息，交由后台处理并将识别结果和人脸信息库中的信息进行匹配比对，若存在相似度大于阈值的人脸信息，则考勤成功；反之则考勤失败，先计成缺课处理。将所有教室里的学生进行考勤后，统计应到学生数和实到学生数，减去对接的教务系统中已请假的学生，最终生成本次的考勤结果，并记录在数据库中。4.3用例和场景4.3.2应用实例业务模型图4-7系统初始用例图初始需求时，由于对一些具体的业务流程还不清楚，在用例描述中可以不记录详细的操作步骤。表4-2课堂管理用例描述用例名称课堂管理用例描述对智慧教室上课时系统进行操作与管理参与者教师与学生4.3用例和场景4.3.2应用实例业务模型表4-3课程管理用例描述用例名称课程管理用例描述对课程信息进行管理，如添加、修改、删除课程信息、课程信息发布、教学班维护等操作参与者教师4.3用例和场景图4-7系统初始用例图4.3.2应用实例业务模型表4-4考勤管理用例描述用例名称考勤管理用例描述对考勤情况进行管理，如添加、修改、删除考勤记录等操作参与者教师、学生4.3用例和场景图4-7系统初始用例图4.3.2应用实例业务模型表4-5教室管理用例描述用例名称教室管理用例描述对上课教室管理，如教室基本信息维护，教室申请等操作参与者教师、楼管4.3用例和场景图4-7系统初始用例图4.3.2应用实例业务模型表4-6设备管理用例描述用例名称设备管理用例描述对智慧教室的设备进行管理，如设备信息录入，设备分配等操作参与者系统管理员4.3用例和场景图4-7系统初始用例图4.3.2应用实例业务模型表4-7用户管理用例描述用例名称用户管理用例描述对智慧教室系统的用户进行管理，如添加教师、添加学生等操作参与者系统管理员4.3用例和场景图4-7系统初始用例图（2）用例迭代需求获取是一个迭代的过程，随着需求获取工作的深入展开，应逐步细化用例和用例描述。4.3用例和场景4.3用例和场景表4-8人脸考勤用例描述用例名称人脸考勤用例描述系统对学生人脸信息进行获取与验证参与者教师基本路径1.教师发出考勤指令（1）教师选择课程的人脸考勤选项（2）发出考勤指令（3）相关设备开始工作2.收集学生人脸信息并识别（1）智慧教室摄像头采集教室内照片（2）摄像头识别出学生人脸交给后台处理（3）后台第三方图像处理软件处理人脸照片（4）将处理的结果与已有的人脸信息库比对（5）比对结果相似度大于90%为考勤成功（6）比对结果相似度小于90%为考勤失败3.对已请假的学生做处理（1）调用考勤管理用例中已请假的学生信息（2）将请假的学生作请假处理4.生成考勤结果并储存（1）将考勤成功、缺勤和请假的学生标记（2）将标记后的结果存入数据库异常路径1.学生在教室但考勤失败，到教师机专用考勤摄像头补录入或者手动考勤2.学生已请假，但是未在教务系统申请图4-8课堂管理用例图4.3用例和场景表4-9AI视频录课用例描述用例名称AI视频录课用例描述AI智能录课，并上传云端供学生课后复习参与者教师和学生基本路径1.教师在智慧教室终端点击上课按钮2.系统提示开始上课3.系统自动录制上课内容4.将录制的内容整理后系统自动上传到智慧教室云课堂5.学生在智慧教室云课堂查看课程内容异常路径1.未在规定时间内上课2.未点击上课按钮图4-8课堂管理用例图4.3用例和场景表4-10智慧白板应用用例描述用例名称智慧白板应用用例描述智慧白板记录上课板书，并上传云端供学生课后复习查看参与者教师与学生基本路径1.教师在智慧教室终端点击上课按钮2.系统提示开始上课3.系统自动记录白板内容4.系统将记录的内容整理后自动上传到智慧教室云课堂5.学生在智慧教室云课堂查看课程内容异常路径1.未在规定时间内上课2.未点击上课按钮图4-8课堂管理用例图4.3用例和场景表4-11智能环境监控用例描述用例名称智能环境监控用例描述智慧教室系统自动监控教室温湿度环境情况并做出调节参与者智慧教室系统基本路径1.教师在智慧教室终端点击上课按钮2.系统提示开始上课3.教室系统智能环境监控开始工作4.环境监控系统记录监控数据5.若监控数据发现异常，自动提醒设备做出调节异常路径1.未在规定时间内上课2.未点击上课按钮图4-8课堂管理用例图4.3用例和场景表4-12课程信息维护用例描述图4-9课程管理用例图用例名称课程信息维护用例描述教师对课程信息进行管理参与者教师基本路径1.在课程管理菜单中选择课程信息管理选项2.选择增加、删除、修改、查询课程信息操作3.输入相关信息并确认课程主要信息：课程号、课程名称、课程简介、课时、学分4.系统将相关数据保存到数据库中4.3用例和场景表4-13课程发布用例描述用例名称课程发布用例描述教师发布课程参与者教师基本路径1.在课程管理菜单中选择要发布的课程选项2.选择可以看到课程发布的对象3.单击发布按钮4.系统提示是否确认发布5.确认后，系统显示发布成功图4-9课程管理用例图4.3用例和场景表4-14教学班维护用例描述用例名称教学班维护用例描述教师对教学班进行管理参与者教师基本路径1.在课程管理菜单中选择教学班管理选项2.选择增加、删除、修改、查询教学班操作3.输入相关信息并确认教学班主要信息：教学班编号、教学班名称、教学班简介、人数、所属学院、学生名单4.系统将相关数据保存到数据库中图4-9课程管理用例图4.3用例和场景表4-15考勤结果修改用例描述图4-10考勤管理用例图用例名称考勤结果修改用例描述教师修改错误的考勤结果参与者教师基本路径1.在考勤管理菜单中选择考勤结果修改选项2.输入学生学号3.选择考勤时间4.输入正确的考勤结果5.单击提交按钮，系统显示修改考勤结果成功4.3用例和场景表4-16考勤结果申诉用例描述用例名称考勤结果申诉用例描述学生申诉错误的考勤结果参与者学生基本路径1.在考勤管理菜单中选择考勤结果申诉选项2.输入学生学号3.选择考勤时间4.输入正确的考勤结果5.单击申诉按钮，系统显示考勤结果申诉提交成功扩展路径1.学生申诉不予通过图4-10考勤管理用例图4.3用例和场景表4-17请假申请用例描述用例名称请假申请用例描述学生在智慧教室系统中提交请假申请参与者学生基本路径1.在考勤管理菜单中选择请假申请选项2.输入学生学号3.选择请假时间4.输入请假原因5.单击申请请假按钮，系统显示申请请假提交成功扩展路径1.不在该课程请假时间范围内，请假失败图4-10考勤管理用例图4.3用例和场景表4-18请假管理用例描述用例名称请假管理用例描述教师在智慧教室系统中审批学生请假信息参与者教师基本路径1.在考勤管理菜单中选择请假管理选项2.选择请假学生3.系统显示请假原因和请假时间4.单击同意按钮，系统显示该学生请假成功，或者单击不同意按钮，系统显示该学生请假不成功图4-10考勤管理用例图4.3用例和场景表4-19教室信息管理用例描述图4-11教室管理用例图用例名称教室信息管理用例描述楼管对教室信息进行管理参与者楼管基本路径1.在教室管理菜单中选择教室信息管理选项2.选择增加、删除、修改、查询教室信息操作3.输入相关信息并确认教室信息包括：教室编号、教室位置、教室类型、座位数量、教室用途4.系统将相关数据保存到数据库中4.3用例和场景表4-20教室使用申请用例描述用例名称教室使用申请用例描述楼管与教师对智慧教室使用申请进行管理参与者楼管与教师基本路径1.教师在教室管理菜单中选择使用申请选项2.选择增加、删除、修改、查询操作3.教师输入相关申请信息并提交申请管理信息包括：申请时间、教室编号、申请用途、申请人编号4.楼管对教室申请信息进行确认5.系统将相关数据保存到数据库中图4-11教室管理用例图4.3用例和场景表4-21设备登记用例描述图4-12设备管理详细用例图用例名称设备登记用例描述系统管理员登记新设备参与者系统管理员基本路径1.在设备管理菜单中选择设备登记选项2.选择需要登记的设备3.输入相关登记信息并点击登记登记信息包括：设备名称、设备型号、生产厂商、产品序列号、登记的时间4.相关信息保存到数据库中4.3用例和场景表4-22设备分配用例描述用例名称设备分配用例描述系统管理员分配设备到智慧教室参与者系统管理员基本路径1.在设备管理菜单中选择设备分配选项2.选择需要分配的设备3.选择需要分配到的教室4.确认后点击分配按钮5.保存到数据库中异常路径1.设备无法分配图4-12设备管理详细用例图4.3用例和场景表4-23用户信息管理用例描述图4-13用户管理用例图用例名称用户信息管理用例描述系统管理员管理用户信息参与者系统管理员基本路径1.在用户管理菜单中选择用户信息管理选项2.选择增加、删除、修改、查询课程信息操作3.输入相关信息并确认教师信息包括：教师号、姓名、性别、密码、手机、头像学生信息包括：学号、姓名、性别、密码、班级、头像、手机号楼管信息包括：楼管账号、姓名、性别、密码、所处大楼、手机号其他人员信息包括：编号、姓名、性别、密码、手机4.系统将相关数据保存到数据库中4.3用例和场景表4-24用户权限管理用例描述用例名称用户权限管理用例描述系统管理员修改指定的用户权限参与者系统管理员基本路径1.在用户管理菜单中选中指定用户2.点击用户权限管理按钮3.对用户权限进行增、删、改操作4.单击保存按钮5.系统提示是否确认保存6.确认后，系统显示保存成功图4-13用户管理用例图4.4用户故事地图用户故事（userstory）是从用户角度来描述用户渴望得到的功能。它是敏捷过程实践中的一个重要环节。一个基本的用户故事包括三个要素：角色、活动、商业价值，其一般描述格式：“作为什么角色，我想要进行什么活动（想要什么功能），以此来实现什么商业价值。”例如一个故事可能是：作为学生可以查看他（她）的考勤记录，以了解出勤情况。4.4.1用户故事4.4用户故事地图极限创始人之一RonJeffries提出了一个关于用户故事的3C描述：（1）卡片（Card）：用户故事一般写在小的记事卡片上。卡片上可能会写上故事的简短描述，工作量估算等。（2）交谈（Conversation）：用户故事背后的细节来源于和客户或者产品负责人的交流沟通。（3）确认（Confirmation）：通过验收测试确认用户故事被正确完成。用户故事通常由客户团队而不是开发人员编写，每个客户团队应包括确保软件符合潜在用户需求的相关人员。整个故事使用商业用语，而不是技术术语。客户团队与开发人员共同确定故事细节并安排故事的优先级顺序。4.4.1用户故事一个好的用户故事应该具有6个特性：1.独立性（Independent）2.可协商性（Negotiable）3.对用户或者客户有价值（Valuable）4.可估算性（Estimable）5.短小（Small）6.可测试性（Testable）4.4用户故事地图4.4用户故事地图用户故事与用例比较：用户故事比用例的范围更小。用例的主要目的是以客户和开发人员都可以接受的格式，记录客户和开发团队之间的协议。用例描述会涉及用户界面和细节问题，并在整个软件生命周期中都存在。用户故事主要目的是用于沟通，启动后期的分析和谈话，它不涉及更多的细节，也不完全对应于用例的主要正常场景，可以被存档或者抛弃。4.4.1用户故事4.4用户故事地图在编写合理的用户故事以后，需要对项目进行估算并制定各类的项目计划。如果以用户故事来描述系统功能，敏捷方法中通常会选用故事点来估算用户故事。故事点是对故事复杂度、工作量或工期的相对估算。例如，一个故事点可以定义为没有打扰情况下一个理想工作日所能完成的工作。4.4.2用户故事估算和计划4.4用户故事地图4.4.2用户故事估算和计划WidebandDelph估算法用迭代方式进行估算：1.所有参与的客户和开发人员聚在一起，由客户随机抽取第一个故事开始，详细讲解故事直到所有人都清楚了解这个故事。2.然后每个开发人员以团队共同定义的一个故事点可以完成的任务为单位，先写下自己估算这个故事的完成时间。3.接着大家展示自己的估算，然后每个人解释为什么估算出这个值。4.经过讨论和再次个人估算，直到经过论证，团队估算出一个所有人都认可的值，再继续下一个故事的估算。4.4用户故事地图4.4.2用户故事估算和计划在估算数个故事后，对估算结果做三角测量：在估算一个故事时，根据这个故事与其他一个或多个故事的关系来估算。假定一个故事估算为4个故事点，第二个故事为2个故事点，把这两个故事放在一起考虑的时候，程序员都应该认可4个故事点的故事大小是2个故事点的故事的2倍，其他3个故事点的故事的大小应该介于4个故事点的故事和2个故事点的故事之间。如果上面的三角测量的结果不对，团队就应该重新估算。4.4用户故事地图4.4.3用户故事地图JeffPatton提出用户故事地图（UserStoryMapping），以结构化的方式来组织用户故事图4-14用户故事地图举例4.4用户故事地图4.4.3用户故事地图图4-15智慧教室用户故事地图的脉络5个主要步骤：（1）产品的定义（2）梳理骨干故事（3）拆分故事（4）确定优先级和发布计划（5）反馈修正故事小结1.了解有关需求的基本知识。2.掌握需求工程的主要活动及它们之间的关系。3.掌握需求获取主要方法。4.掌握通过用例和场景对需求建模。5.掌握用户故事地图建立项目需求。作业与思考作业：1.试对智慧教室的物联设备做进一步探究，了解相关的应用领域

，建立物联设备的术语表。2.请设计教材以外的一个智慧教室的应用场景，并对本节中的用例加以改进。3.请给出“查看考勤结果”用例描述。4.选取一个实例，用用户故事地图来建立实例的二维视图。思考：1.如何理解“如果产品能以20%的功能满足80%的人的需求，那么这个产品就成功了一大步”这句话。它的背后隐含着什么定律或者原则。第5章

需求分析本章学习目标1.理解需求分析的主要任务。2.理解不同需求分析方法解决问题的本质3.掌握传统的结构化分析方法。4.掌握面向对象的分析方法。5.熟练应用UML建立需求分析模型。6.了解软件形式化分析技术。

面向数据流的结构化分析1形式化分析技术5结构化分析实例2面向对象的分析3面向对象分析实例4需求分析的主要任务在需求工程的起始阶段，项目利益相关者建立起基本的问题需求，定义重要的项目约束条件并描述项目的功能和主要特征。这些信息经过各种需求收集活动后，在需求导出阶段记录下来。在进入需求的精化阶段，需求会得到进一步的精炼，并扩展为分析模型。创建需求分析模型原则Ariow和Neustadt提出了在创建需求分析模型时应注意的原则：（1）分析模型应关注问题域或业务域内可见的需求，并注意提高抽象级别。（2）分析模型的每个元素都应能增加对软件需求的整体理解，并提供对信息域、功能和系统行为域的深入理解。（3）关于基础结构和其他非功能的模型应推迟到设计阶段再考虑。（4）应最小化整个系统内的关联，减少类和功能间的直接依赖关系和相互作用。（5）确认分析模型为项目所有利益相关者都能带来价值。（6）尽可能保持模型简洁。需求建模方法在需求建模过程中，软件工程具体关注的焦点是“系统要做什么”，而不是“系统该怎么做”。关注的主要问题有“在特定的应用环境下，发生了哪些用户交互？系统处理哪些对象？系统必须执行什么功能？系统对外界展示什么行为？系统与外界有哪些接口？受到什么样的约束？”等。需求建模方法传统的面向数据和面向处理的需求建模方法被称为结构化分析，其中处理是将数据作为独立实体加以转换，表示了数据对象在系统内流动时，系统是如何处理和如何转换数据。面向对象的需求分析方法，则是关注于识别和定义类，通过类之间的协作来响应客户的需求。5.1.1半形式化分析技术（1）数据流图数据流图有时也被称为数据流程图（DataFlowDiagram，简称DFD），是一种便于用户理解和分析系统数据流程的图形工具。表5-1数据流程图基本符号5.1面向数据流的结构化分析5.1面向数据流的结构化分析在绘制分层数据流图时应注意以下事项：①自顶向下、逐层分解。②数据流必须经过加工环节。③每个加工必须既有输入数据流，又有输出数据流。④数据存储环节一般作为两个加工环节的界面来安排。⑤适当地为数据流、加工、数据存储、外部实体命名，名字应反映该成分的实际含义，避免空洞的名字。在绘制分层数据流图时应注意以下事项：⑥编号。⑦保持数据守恒。⑧局部数据存储的隐蔽性。⑨保持父图与子图平衡。⑩只绘制所描述的系统稳定工作情况下的数据流图。⑪画数据流而不要画控制流。5.1面向数据流的结构化分析（2）判定树和判决表判定树又称决策树（decisiontree），是一种描述加工的图形工具，适合描述问题处理中具有多个判断，并且每个决策与若干条件有关，导致不同的结果。5.1面向数据流的结构化分析例如有关退票改签费有如下规定：

开车前8天（不含）以上退票的，不收取退票费；票面乘车站开车时间前48小时以上的按票价5%计，24小时以上、不足48小时的按票价10%计，不足24小时的按票价20%计。办理车票改签时，新车票票价高于原车票的，收取票价差额。新车票票价等于原车票，不收取费用。新车票票价低于原车票的，退还差额。5.1面向数据流的结构化分析图5-1判定树表示购票5.1面向数据流的结构化分析表5-2购买火车票判定表5.1面向数据流的结构化分析（3）数据字典数据字典是元数据(metadata)的结构化存储库，它提供所用数据的全面描述。其主要目的是提供一种共同的语言，以帮助软件项目的涉众理解数据、数据的含义以及数据与其他数据元素的关系。在结构化分析中，数据字典的作用是给数据流图中每个成分加以定义和说明，数据流图和数据字典共同构成系统的逻辑模型。5.1面向数据流的结构化分析1.数据项：数据流图中数据块的数据结构中的数据项说明。数据项描述={数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系}2.数据结构：数据流图中数据块的数据结构说明。数据结构描述={数据结构名，含义说明，组成：{数据项或数据结构}}3.数据流：数据流图中流线的说明。数据流描述={数据流名，说明，数据流来源，数据流去向，组成：{数据结构}，平均流量，高峰期流量}4.数据存储：数据流图中数据块的存储特性说明。数据存储描述={数据存储名，说明，编号，流入的数据流，流出的数据流，组成：{数据结构}，数据量，存取方式}5.处理过程：数据流图中功能块也就是加工的说明。处理过程描述={处理过程名，说明，输入：{数据流}，输出：{数据流}，处理：{简要说明}}5.1面向数据流的结构化分析5.1.2

Gane和Sarsen结构化系统分析Gane和Sarsen的结构化系统分析方法作为主流的传统需求分析技术是以系统中数据流动为重点，对数据出入系统边界形态、系统内部处理进行研究来分析用户的要求。其分析过程分为9个步骤。5.1面向数据流的结构化分析分析过程分为以下9个步骤：（1）在需求初步获取的基础上运用逐步求精的方法画数据流图，数据流图分层描述。（2）决定软件系统实现数据流图中哪些部分。（3）确定数据流图中数据流的细节。（4）定义数据流图中加工的处理逻辑。（5）定义数据流图中涉及的数据存储。（6）定义满足项目需要的物理资源。（7）确定项目需要满足的输入－输出规格说明。（8）确定系统中输入数据、中间计算结果、输出数据的大小。（9）根据步骤（8）中的计算结果，确定硬件要求和约束。5.1面向数据流的结构化分析5.2结构化分析实例5.2.1逐步求精数据流图智慧教室是一个较为复杂的问题，一次性得到一张完整的DFD比较困难，可以按照系统抽象层次结构进行逐步求精，并采用分层数据流图表示。图5-2顶层数据流图图5-3第一次细化数据流图5.2结构化分析实例图5-4课堂管理细化数据流图5.2结构化分析实例图5-5人脸考勤管理细化数据流图5.2结构化分析实例5.2.2定义数据字典表5-3人脸考勤管理数据字典部分词条5.2结构化分析实例5.2.3建造实体-关系模型5.2结构化分析实例面向对象分析5.3.1面向对象方法和结构化方法结构化方法求解问题的基本策略是从功能的角度审视问题域。它将应用程序看成实现某些特定任务的功能模块。在每个功能模块中，用数据结构描述待处理数据的组织形式，用算法描述具体的操作过程。在面向对象的技术中，对象由数据和操作组成。对程序设计者而言，对象是一个具有信息性内聚的程序模块；对其他用户而言，对象是程序提供给他们的服务，通过知悉对象接口形式就可以调用，并不需要了解它们的内部实现细节。5.3面向对象分析5.3.2面向对象分析中的主要技术面向对象分析（OOA）是一种半形式化的分析技术。在多种面向对象的软件工程方法中，比较有影响的应用有Booch、OOSE、OMT，以及后面出现的统一过程等。5.3面向对象分析5.3.2面向对象分析中的主要技术GradyBooch是面向对象方法最早的倡导者之一。他于1986年提出了“面向对象分析与设计（OOAD）”。

Booch提出的开发模型包括逻辑模型、物理模型、静态模型和动态模型。①发现类和对象，在一定抽象层面标识出类和对象；②确定类和对象的语义，将期望的行为赋予对象类；③标识类和对象之间的关系。Booch方法有很强的表达能力，其迭代和增量的思想对很多软件工程开发设计阶段的建模提供了重要的指导。5.3面向对象分析OMT（ObjectModelingTechnique）方法是由Loomis，Shan和JamesRumbaugh在最先提出的实体和关系模型基础上进一步扩展了类、行为以及继承等得来。①对象模型：表述对象静态的结构以及它们之间的相互作用关系。②动态模型：描述系统动态的变化特点，包括状态和活动等。③功能模型：描述与数据值的变换有关的系统特征，不同数据值之间在系统内的转换，包括处理、数据存储、数据流等概念。5.3面向对象分析Jacobson提出了“面向对象软件工程（OOSE）”方法，其核心是用例驱动，建立面向对象的分析模型和设计模型。主要用五种模型来描述系统：①需求模型（Requirementmodel，简称RM）。②分析模型（Analysismodel，AM）。③设计模型（Designmodel，简称DM）。④实现模型（Implementationmodel，IM）。⑤测试模型（Testingmodel，简称TM）。OOSE的开发活动主要包括分析、构造、测试三个过程。5.3面向对象分析统一过程使用统一建模语言（UnifiedModelingLanguage，简称UML）来表示要开发的软件。UML是面向对象开发中一种通用的图形化建模语言。基于UML建模可以分为静态和动态两类：基于用例图、对象图以及类图等创建的模型为静态模型，基于状态图、活动图等创建的模型为动态模型。表5-4UML部分语法描述5.3面向对象分析5.3.3面向对象的分析方法和主要步骤面向对象分析的目标主要是完成对求解问题的分析，建立系统的需求分析模型，包括对象模型、动态模型和功能模型等。（1）对象模型：对用例模型进行分析，把系统分解成互相协作的分析类，通过类图和对象图描述对象、对象的属性以及对象间的关系。对象模型是对系统的静态建模。（2）动态模型：描述系统的动态行为，通过顺序图、协作图描述对象的交互，以揭示对象间如何协作来完成每个具体的用例。单个对象的状态变化、动态行为可以通过状态图来表示。（3）功能模型：描述系统应该做什么，最直接地反映了用户对目标系统的需求。通常功能模型由一组数据流图或一组用例图组成。5.3面向对象分析5.3.3面向对象的分析方法和主要步骤可以把面向对象的分析过程分成三个主要活动：用例建模、类建模和动态建模。(1)

用例建模：建立以用例模型为主体的需求模型，提出所有用例的场景，又称功能建模。(2)类建模：确定类和它们的属性，以及类间的相互关系和交互作用。(3)动态建模：确定由每个类或者子类执行的活动或对它们进行的行为。5.3面向对象分析5.3.3面向对象的分析方法和主要步骤面向对象分析从抽取类开始。5.3表5-5

类的构造表达面向对象分析5.3.3面向对象的分析方法和主要步骤实体类的提取可以按照如下步骤进行：1）提出所有用例的可能场景，包括正常场景和异常场景。2）标识出这些用例和场景中的实体类（包括属性和方法，

也可以在面向对象设计时深入探索）。3）确定实体类结构和层次。4）确定实体类之间的交互关系。5.3面向对象分析5.3.3面向对象的分析方法和主要步骤用例是系统功能的一般性描述，场景是用例的一个特定实例。系统每个用例可以通过由实体类、边界类、控制类相互关联的类图来表示。用例的场景通过这些类的对象之间的交互关系和交互行为来实现，可以通过顺序图、协作图等来对这个场景进行动态建模。在面向对象分析过程中，有多种方法可以帮助提取实体类。5.3面向对象分析5.3.3面向对象的分析方法和主要步骤（1）用例识别从用例和场景中识别类是提取类的一种主要方法。针对每个用例，我们可以通过回答以下问题来识别出候选类：①用例或者场景描述，需要哪些实体参与合作以完成任务？②用例或者场景描述中，会生成或者存储哪些需要长期保存的信息？③用例使用者需要向用例输入的信息有哪些？④用例向使用者输出的信息有哪些？⑤用例需要对哪些设备进行操作？5.3面向对象分析（2）名词识别法首先用指定语言对系统进行简要的描述，通常用一个段落即可；接着从这段描述中标识出名词、代词、名词短语，并将其表示成初始的候选类；然后通过回答以下问题进一步确定类。①是否存在两个及以上类，表述的是同一个信息，删除冗余的候选类，仅保留一个具有描述能力的候选类。②删除处于系统边界之外的类，即去掉不相干的候选类。③删除定义不确切，或者范围过大的模糊的候选类。④删除独立性不清，应该属于类的属性的候选类。⑤删除独立性不强，应该属于类的操作的候选类。5.3面向对象分析（3）CRC卡片1990年Wiener提出了类—职责—协作建模（Class-Responsibility-Collaboration，简称CRC）。CRC模型在开始时是用卡片记录，将每个类的类名、功能（职责）和它要需要调用其他类的列表放在一张卡片中。5.35.4.1功能建模表5-6查看考勤结果用例场景描述面向对象分析实例5.45.4.1功能建模图5-7查看考勤结果活动图面向对象分析实例5.4面向对象分析实例5.4.1功能建模表5-8

活动图基本组成描述5.45.4.2类建模根据人脸考勤用例可以得到下列类：（1）实体类①考勤记录：记录用户每一次的考勤结果。②采集人脸信息：保存教室现场采集的考勤人脸特征信息。③学生信息：保存学生信息包括学生人脸信息。（2）控制类①人脸考勤：负责处理考勤过程中系统特定指令和动作。（3）边界类①摄像头接口：负责获取教室图像信息。②教师界面：教师与系统交流的媒介。面向对象分析实例5.45.4.2类建模图5-8考勤管理用例的初始类图面向对象分析实例5.45.4.2类建模图5-9用户管理用例的初始类图面向对象分析实例5.45.4.2类建模图5-10智慧教室管理系统部分用例合并得到的初始类图面向对象分析实例5.45.4.3动态建模

（1）状态图表5-9状态图基本组成描述面向对象分析实例5.45.4.3动态建模

在状态图中，事件（Event）、动作（Action）、以及活动（Activity），在描述状态之间的转换和状态行为时起着关键作用。事件是引起状态转换或触发状态中行为的触发器。它可以是外部的信号、条件的改变、用户的操作等。事件表示状态变化的原因或起因。动作是在状态机中执行的某种行为或操作，它通常与状态转换相关联，描述了状态从一个状态到另一个状态的具体动作。动作是状态机中可以执行的原子操作。活动是状态机中一个状态执行的一系列操作或任务。它是状态中进行的非原子操作，可以描述状态内部的活动流程，而不是仅仅描述状态之间的转换。面向对象分析实例5.45.4.3动态建模

（1）状态图图5-11学生考勤状态图面向对象分析实例5.45.4.3动态建模

（2）顺序图表5-10顺序图基本组成描述面向对象分析实例5.45.4.3动态建模

（2）顺序图图5-12人脸考勤顺序图面向对象分析实例5.45.4.3动态建模

（2）顺序图图5-13教师查询考勤记录顺序图面向对象分析实例5.45.4.3动态建模

（3）协作图表5-11协作图中的部分符号面向对象分析实例5.45.4.3动态建模

（3）协作图图5-14教师查询考勤结果协作图面向对象分析实例5.4形式化分析技术形式化方法（FormalMethods）是验证软件系统是否高度安全可靠的重要方法，是提高软件质量的有效途径。在软件工程领域，形式化方法是基于数学的描述和验证软件系统的一种方法。形式化方法利用数学的严密性去证明系统的正确性，形成一套严密的理论体系，提供一个完整的框架，使得人们可以在这个框架中以一种系统的方式描述和验证软件系统。5.5形式化方法可以分为以下五类：（1）基于模型的方法：通过明确定义状态和操作来建立一个系统模型，显式说明系统如何从一个状态转换到另一个状态，例如Z语言、VDM和B方法等。（2）基于网络的方法：采用具有形式语义的图形语言，例如Petri网、状态机等。（3）进程代数方法：通过限制所有容许的可观察的进程间通信来表示系统行为，允许并发进程的显式表示，例如通信顺序进程CSP、通信系统演算CCS、时序排序规约语言LOTOS、计时通信顺序进程TCSP、计时可能性演算TPCCS等。形式化分析技术5.5形式化方法可以分为以下五类：（4）基于逻辑的方法：用逻辑描述系统底层规约、时序和行为等，采用与所选逻辑相关的公理系统证明系统达到预期目标。利用具体的编程构造扩充逻辑，通过保持正确性的细化步骤集来开发系统。这类方法有各类时序逻辑TL、hoare逻辑、WP演算、模态逻辑等。（5）代数方法：通过将未定义状态下不同的操作行为相联系，给出操作的显式定义。这类方法有OBJ、Larch族代数规约语言等。形式化分析技术5.5汽车无钥匙进入系统CSP模型//模型需要的常量定义#defineN2;//车钥匙拥有者数目（2人）#definefar0;//人离汽车远#definenear1;//人离汽车近，有钥匙的话可以开车门#definein2;//人在车里#defineoff0;//汽车发动机关#defineon1;//汽车发动机开#defineunlock0;//车门关闭但没锁#definelock1;//车门锁住#defineopen2;//车门开着#defineincar-1;//钥匙在车里#definefaralone-2;//钥匙不在车里且离车很远形式化分析技术5.5//模型需要的变量定义varowner[N]={far,far};//人的位置，编号分别是0和1，初始时2人都离车很远varengine=off;//发动机状态，初始时关闭vardoor=lock;//车门的状态，初始时门是锁住的varkey=0;//车钥匙归属，初始时在0号人处varmoving=0;//汽车移动状态，0是停止，1是移动varfuel=10;//发动机油耗，1表示短距离，5表示长距离//人的行为模型，其中i表示人的编号（这个模型中可以是0也可以是1），“[]”表示前后连接的行为可以任意选择，“[条件]”表示满足条件才能进行条件后的行为（斜体字部分），“{运算}”表示行为发生时改变一些变量的值，箭头表示行为发生先后顺序，“&&”和“||”分别表示逻辑并或者逻辑或owner_pos(i)=[owner[i]==far]towards.i{owner[i]=near;}->owner_pos(i)[][owner[i]==near]goaway.i{owner[i]=far;}->owner_pos(i)[][owner[i]==near&&door==open&&moving==0]getin.i{owner[i]=in;}->owner_pos(