第5讲需求分析与验证

需求分析与验证教材P117第5章先思考几个问题？需求获取涉及的UML图形？（回顾）需求获取过程模型？（回顾）2023/2/42阅读书的第五章回答下列问题？需求分析使用的UML图形有哪些？需求分析的过程模型包括哪些活动？如何确定需求的优先级？10分钟2023/2/43第五章需求分析与验证

5.1分析模型的表示

顺序图、通信图、状态图5.2需求分析的过程模型

5.3需求优先级分析

5.4用例分析5.5利用快速原型辅助需求分析5.6评审分析模型

5.7需求规约

5.8需求验证

2023/2/44第五章需求分析与验证5.1分析模型的表示

5.1.1顺序图

5.1.2通信图

5.1.3状态图

2023/2/455.1分析模型的表示在用例模型已成的情形下为何还要构建分析模型？2023/2/46分析模型的表示构建分析模型的两点理由：⑴分析模型比用例模型更加结构化、更加清晰直观。⑵分析模型是用例模型与软件设计模型之间的“桥梁”。2023/2/47分析模型的表示参与者：需求工程师。软件架构师、利益相关方，以及项目软件经理、质量保证工程师。输入与输出：输入制品与需求获取活动的输出制品相同。在所有这些输入制品中，用例模型最重要。输出制品主要是软件需求的分析模型。该模型是需求规约的主要组成部分，同时也是后续软件设计、构造和测试活动的工作基础。2023/2/485.1分析模型的表示2023/2/49顺序图分类：交互图包括顺序图和通信图两种。前者强调消息传递的时间序，后者突出交换消息的对象之间的合作关系。虽然它们各有侧重，但从语义上讲基本等价，可从一种图自动转换为另一种图。2023/2/410顺序图交互图的作用：业务分析及需求分析人员？软件设计及实现人员？测试人员？课程注册管理系统中“制订选课计划”用例的顺序图2023/2/411图5.1课程注册管理系统中“制订选课计划”用例的顺序图2023/2/4125.1.2通信图通信图是顺序图的另一种表现形式。如，图5.5是与图5.1所示的顺序图等价的通信图（除注解外）2023/2/4132023/2/414图5.5课程注册管理系统中“制订选课计划”用例的通信图（三）顺序图与通信图之间的选取顺序图和通信图互为派生视图，建模者往往面临选用顺序图还是通信图的困惑。建议读者依次考虑以下规则（前面的规则优先级较高）：⑴当需要强调消息传递的时间序时采用顺序图；

当需要强调对象之间的交互、协作关系时采用通信图。⑵当刻画用例的动作序列时，采用顺序图；

当刻画软件内部等某项功能的实现构想时，采用通信图。⑶在业务分析和需求建模阶段，优先考虑顺序图；在设计和实现阶段，优先考虑通信图。2023/2/4155.1.3状态图定义：状态图描述一个实体在事件刺激下的反应式动态行为。构成：状态、事件以及响应动作。实体可以是对象，软件系统（或其子部分）或其中一个软构件，整个大系统。作用：状态图可用来描述实体的行为。2023/2/416图5.6课程注册管理系统中“课程设置”

类的典型对象的状态图2023/2/4175.2需求分析的过程模型如何展开需求分析？应该遵循何种过程模型来展开需求分析？需求分析的主要任务是：建立比用例模型更完整、更精细的分析模型，以期获得对软件需求的更深入理解，提高软件需求的质量，为软件设计奠定更坚实的基础。2023/2/418需求分析的过程模型用例驱动的需求分析过程的主要活动如下⑴需求优先级分析。⑵用例分析。⑶分析模型评审。⑷为辅助需求分析而构建快速原型。这些活动可按序组织为需求分析工作流。图5.12需求分析工作流2023/2/4195.3需求优先级分析主要任务：确定每项需求优先级。三种不同的诠释方法：⑴基于实现紧迫度的优先级(其他两个略)高优先级必须实现的需求项；中优先级最终必须实现的需求项，至下一软件版本再实现；低优先级

“锦上添花”式的需求项，趋于完美。2023/2/420表5.1家庭保安系统的需求优先级序号用例/质量需求项名称优先级说明1开关机及复位处理高必须完整实现2系统配置高同上3传感器监测高同上4日志查询中应该实现其中大部分功能5性能：Req-Performance-001~002高对产品可接受度的影响最大6可靠性：Req-Reliability-001~003高同上7安全性：Req-Authentication-001和Req-Authorization-001高同上8可配置性：Req-Config-001高同上9安全性：Req-Audit-001中对产品可接受度有一定影响10易用性：Req-EasyUse-001~002中同上11可扩展性：Req-Extend-001中同上12可伸缩性：Req-Scalability-001中同上13兼容性：Req-Compatibility-001低可以不予实现，但其实现可以增强产品可接受度14本地化与国际化：Req-Intl-001低同上2023/2/421用例分析用例分析的子活动归纳如下：⑴精化领域概念模型；⑵设置分析类；⑶构思分析类之间协作关系；⑷导出分析类图。2023/2/422图5.13家庭保安系统的领域概念模型（精化）2023/2/4235.4.2设置分析类分析类：是指直接服务于软件的功能性需求的概念层面的类，它与待开发软件系统的具体实现技术无关。从功能需求的角度看，用例的业务逻辑处理功能主要由边界类、控制类和实体类三种分析类协同完成。2023/2/424边界类：负责目标软件系统与外部执行者之间的交互。

控制类：用例任务的责任承担者，负责协调、控制其他类共同完成用例规定的功能或行为。实体类负责保存目标软件系统中具有持久意义的信息项并向其他类提供信息访问的操作。2023/2/4255.4.2设置分析类5.4.3构思分析类之间的协作关系将用例模型中的用例描述转化成UML交互图构造交互图的关键在于将用例的各项功能分解并分派至合适的分析类交互图有助于需求工程师更深入地理解、分析软件需求，剔除用例描述中的模糊性、不一致性、不完整性，同时也为后续的软件设计奠定基础。2023/2/426图5.16“传感器监测”用例的顺序图

2023/2/4275.4.4导出分析类图将消息的响应对应到分析类的职责，从而推动分析模型的建立和精化，持续迈向软件设计和编程实现。从用例描述中的事件及动作序列，到交互图中的消息，再到分析类的职责，最后演变为设计元素的功能或方法，这个进化过程是面向对象分析与设计过程的关键2023/2/428（一）创建初始的分析类图比较并研究领域概念模型和交互图，以领域概念模型为基础创建初始的分析类图。如果交互图中出现了某个对象，其所属的分析类未在领域概念模型中出现，则应在分析类图中添加此分析类；反之，针对领域概念模型中的类，如果其对象未在任何交互图中出现，则需求工程师必须判断该类是否对用户需求的实现有所贡献。2023/2/429图5.18家庭保安系统的分析类图（初步）2023/2/430（二）根据消息确定分析类的职责（三）根据消息传递确定分析类之间的连接（四）根据交互图确立分析类的属性（五）整理分析类图2023/2/431图5.21家庭保安系统的分析类图2023/2/432例5.10

导出分析类图5.5利用快速原型辅助需求分析原型的分类：探索性原型实验性原型进化性原型2023/2/4335.6评审分析模型参与人员：需求工程师、软件设计师、项目软件经理、利益相关方的代表和业务专家任务：正式地审查需求优先级、基于UML的分析模型（含分析类图、交互图、状态图、活动图），快速原型等分析模型是被评审的主体对象。2023/2/4345.7需求规约需求规约：需求工程师经需求获取的分析后形成的软件文档。需求规约主体内容：软件需求的用例模型和分析模型。需求规约的作用是什么？2023/2/4355.8需求验证⑴需求评审。⑵问题整理。⑶问题求解。⑷达成一致。2023/2/436需求工程习题详见