❖ 参考书目：包含了对所有和该软件相关的文档的引 用，其中包括其他的软件工程文档、技术参考文献、 厂商文献以及标准。
❖ 附录：包含了规约的补充信息，表格数据、算法的 详细描述、图表以及其他材料。
需求验证
❖ 需求验证目的是要检验需求是否能够反映用户的意愿 ❖ 评审人员评审时往往需要检查以下内容：
1. 系统定义的目标是否与用户的要求一致； 2. 系统需求分析阶段提供的文档资料是否齐全；文档中的描述
1、问题分解
❖ 什么是问题分解
降低解决问题的复杂度; 获取和分析问题本身所 固有的整体-部分关系
图书馆系统
❖ 读者管理 ❖ 图书管理 ❖ 借阅管理
子问题1
整个问题 子问题3
子问题2
2、问题抽象(1/2)
❖ 什么是抽象?
抓住问题的本质,获取一般和特殊关系
问题抽象(2/2)
❖ 读者抽象(提取成份)
❖ 什么是多视点分析
从多个角度、不同层面上分析和描述用户需求
❖ 为什么需要多视点分析
人的认识具有片面性(瞎子摸象) 多视点可以帮助我们全面把握用户的需求
❖ 多视点分析：
例如围绕着超市收银系统
❖ 顾客希望？ ❖ 收银员希望？ ❖ 经理希望？ ❖ 系统管理员希望？
最终的软件系统是相关方的综合体，各种期 望可能存在冲突，需要进一步分析权衡
❖ 功能描述：描述解决问题所需的每个功能。其中包 括，为每个功能说明一个处理过程；叙述设计约束； 叙述性能特征；用一个或多个图形来形象地表示软 件的整体结构和软件功能与其他系统元素间的相互 影响。
❖ 行为描述：描述作为外部事件和内部产生的控制特 征的软件操作。
❖ 检验标准：描述检验系统成功的标志。即对系统进 行什么样的测试，得到什么样的结果，就表示系统 已经成功实现了。它是“确认测试”的基础。
❖ 会议应该讨论那些非正式讨论不能解决 的问题
❖ 通常会议分为三个阶段：
叙述阶段 讨论阶段 决策阶段
内容摘要
❖需求工程概述 ❖需求获取 ❖需求分析、协商与建模 ❖需求规约与验证 ❖需求管理
需求规约的原则-1
❖从现实中分离功能，即描述要“做 什么”而不是“怎样实现”
认识模型，而不是设计或实现的模型 使用面向处理的规约语言(或称系统定义语言)
需求调研实例—学生选课系统
❖ 第一阶段：了解基本情况
请教务处老师介绍背景，如学生总数、课程数量、选课 相关的基本制度等
❖ 第二阶段：制订访谈计划，深入讨论相 关需求
除了学生还有哪些相关用户? 选课规则(学分、课程人数限制等)、退课规则 了解客户ຫໍສະໝຸດ 系统的期望：准确、访问速度快… ……
需求调研实例—学生选课系统
名字 性别 单位 类别 照片 Email 电话
3、需求建模(1/2)
❖ 什么是需求模型 ❖ 为什么需要建模
需求建模(2/2)
❖ 注意
不要涉及软件设计和实现细节
❖ 需求建模方法
面向数据流的结构化分析方法 (SA) 面向数据结构的分析方法 面向对象的分析方法 (OOA)
4、多视点分析
需求工程的六个阶段
❖需求获取：资料收集 ❖需求分析与协商：理解分析整理 ❖系统建模：用模型描述(写下来) ❖需求规约：完善需求文档并定稿 ❖需求验证：验证确认 ❖需求管理：整体规划及变更管理
内容摘要
❖需求工程概述 ❖需求获取 ❖需求分析、协商与建模 ❖需求规约与验证 ❖需求管理
需求获取方法与策略
需求规约的原则-2
❖ 规约必须包括系统运行环境 ❖ 规约必须是可操作的
需求规约的原则-3
❖ 规约必须允许不完备性并允许扩充 ❖ 规约必须局部化和松散耦合
需求规约
❖ 引言：陈述软件目标，在基于计算机的系统语境内 进行描述。
❖ 信息描述：给出软件必须解决问题的详细描述，记 录信息内容和关系、流和结构。
内容摘要
❖需求工程概述 ❖需求获取 ❖需求分析、协商与建模 ❖需求规约与验证 ❖需求管理
❖ Alan Davis 把需求工程定义为“直到 （但不包括）把软件分解为实际架构构 件之前的所有活动” (强调做什么)
❖ Herb Krasner定义了需求工程的五阶段 生命周期：需求定义和分析、需求决策、 形成需求规格、需求实现与验证、需求 演进管理
❖1、建立与用户、开发人员、分析人 员之间顺畅的通信途径
❖2、深入客户方进行访谈与调查 ❖3、观察用户操作流程 ❖4、组成各方联合小组 ❖5、使用基于用况(Use Case)的方法
访谈与调查的原则
❖ 所提问的问题应该循序渐进 ❖ 不要限制用户对问题的回答 ❖ 提问和回答在汇总后应能够反映用户
需求的全貌——不断汇总-反馈-汇总
用实例说明需求工程的设计原则 和描述方法
计算机学院 关皓文 201313273
需求的定义
用户解决一个问题或达到一个目标所需要的一种 状况或能力(主观需求)
系统为了满足一种约定、标准、规格说明或其它 正式文件而必须满足或拥有的一种状况或能力 （客观需求）
以上两种状态或能力的文档化表示（需求文档）
需求分析原则
❖ 必须能够表示和理解问题的信息域(数据)
❖ 必须能够定义软件将完成的功能
❖ 必须能够表示软件的行为(作为外部事件 的结果)
❖ 必须划分描述数据、功能和行为的模型 (分离描述)，从而可以分层次地揭示细节
❖ 分析过程应该在基本信息基础上不断细化
需求描述和分析技术
1. 问题分解 2. 抽象 3. 建模 4. 多视点
是否完整、清晰、准确地反映了用户要求； 3. 被开发项目的数据流与数据结构是否确定且充足； 4. 主要功能是否已包括在规定的软件范围之内，是否都已充分
❖ 第三阶段：基本了解需求后就一些关键细节 通过问卷进行明确
在已经了解总体选课人数之后，需要进一步了解通常情 况下的选课持续时间、是否按院系逐步开放选课、选课 人数的一般分布等—与性能设计密切相关
推荐关键管理人员使用USB Key设备，经济上是否可以 接受
……
内容摘要
❖需求工程概述 ❖需求获取 ❖需求分析、协商与建模 ❖需求规约与验证 ❖需求管理
需求协商
❖ 讨论需求冲突，折衷方案 ❖ 协商不是简单的逻辑或技术上的争论 ❖ 要注意组织和行政方面的因素
不一致的目标 责任的丧失或转移 组织文化 组织管理态度和士气 部门差异
❖ 通常会议是解决冲突最快的方式
❖ 参加者：发现冲突、遗漏或重叠的分析 员，以及可以解决发现的问题的项目相 关人员