1、第二讲. 需求基础,主要内容,需求的涵义 需求的类型 需求工程的路线 优秀需求的特性 常见的需求错误,研究对象：软件加强型系统中的软件,泛指由计算机技术支持的互相联系 着的一组人类活动组成的系统 与物理设备相关 与人类社会的活动相关,软件加强型系统,比如：游戏软件与物理设备、用户 ERP系统与组织运作过程,1.需求的涵义 对象,1.需求的涵义 需求的定义,（1）用户为了解决问题或达到某些目标所需要的条件或能力； （2）系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或能力； （3）对（1）或（2）中的一个条件或一种能力的一种文档化表述。,1.需求的涵义 问题域与
2、解系统（1）,软件系统与外部环境,1.需求的涵义 问题域与解系统,当现实的状况与人们期望的状况产生差距时，就产生了问题。 要解决问题，就需要改变现实当中某些实体的状态或改变实体状态变化的演进顺序，使其达到期望的状态或演进顺序。 这些实体和状态构成了问题解决的基本范围，称为该问题的问题域（Problem Domain） 软件系统通过影响问题域，能够帮助人们解决问题，称为解系统,1.需求的涵义 共享现象,软件系统能够与问题域进行交互和相互影响的原因在于，软件系统中的某些部分对问题域中的某些部分的具有模拟特性。 换句话说，软件系统当中含有问题域某些部分的模型（或模拟），常见的模型包括数据模型、对象模
3、型、处理模型等。 问题域中的某些信息能够和模型中的信息建立映射关系 这些通过映射建立的共同知识，就是问题域和解系统之间的共享现象,1.需求的涵义 需求,需求是用户对问题域当中的实体状态或事件的期望描述 R2.2.3-1：一旦书籍被借出，则在归还之前，它不能被再次借阅。 R2.2.3-2：在归还的书超过30天的归还期限时，归还后应该进行超期处罚。 直接需求 间接需求,1.需求的涵义 规格说明,规格说明是解系统为满足用户需求而提供的解决方案，规定了解系统的行为特征 主要包括两个部分（如图23(b)）： （1）对共享现象（模型）的描述； （2）系统对共享现象所施加的操作的描述。 也可以看作是一种需求
4、 完全针对系统行为发出的期望 一种理想的、完全不需要进行任何额外努力即可以转换为系统行为的需求。,1.需求的涵义 问题域特性,问题域自治的规律性称为问题域特性 包括结构特性和行为特性等 问题域特性的重要性 要想解决问题，它就需要了解问题域特性，将解决方案和问题域特性结合起来 要防止解系统的引入在问题域当中引发未预见的连锁反应 需要关注的问题域特性 间接特性 约束和假设,1.需求的涵义 从问题域、需求和规格说明的关系看需求工程,描述明确的问题域特性E; 定义良好的系统行为S ; 预期的需求R 需求工程的目的就是根据E，构建S，使得 需求工程的困难之处： （1）不存在描述明确的E； （2）不存在确
5、定的针对S的评估标准R； （3） 是一个创造性的过程。 需求工程的主要工作 需求开发,确定 R 研究问题背景，描述问题域特性E 构建解系统，描述解系统行为S，使得,主要内容,需求的涵义 需求的类型 分类方式 功能需求 性能需求 质量属性 对外接口 约束 需求工程的路线 优秀需求的特性 常见的需求错误,2.1 需求的分类方式 (1),功能需求（Functional Requirement）： 和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。 性能需求（Performance Requir
6、ement）： 系统整体或系统组成部分应该拥有的性能特征，例如CPU使用率、内存使用率等。 质量属性（Quality Attribute）： 系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，例如可靠性程度、可维护性程度等。 对外接口（External Interface）： 系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等等。 约束 进行系统构造时需要遵守的约束，例如编程语言、硬件设施等,2.1 需求的分类方式(2),系统需求（System Requirement） 硬件需求（Hardware Requirement） 软件需求（Software R
7、equirement） 其他需求,2.1三类问题和三种需求变化方式,S类型程序（可说明的） 问题能够被形式地和完全地陈述出来 接受：按照这个规格说明，这个程序是正确的吗？ 这种软件不会进化 对规格说明的改变定义一个新的问题，因而是新的程序 P类型程序（问题求解） 现实世界问题的不精确陈述 接受：对这个问题来说，这个程序是一个可接受的解决方案吗？ 这种软件很可能要连续地进化 因为这个方案是决不会完美的，并且是能够被改进的 因为现实世界要变化，所以这个程序也要变化 E类型程序（被嵌入的） 一个变成它建模的世界的一部分的系统 接受：完全依赖于观点和判断 这个软件是固有的进化的 软件和世界的变化相互影
8、响,2.1三类问题和三种需求变化方式,2.2 功能需求 层次性,2.2 功能需求 业务需求,系统建立的战略出发点，表现为高层次的目标（Objective），它描述了组织为什么要开发系统 为了满足用户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性（Feature） 参与各方必须要对高层次的解决方案达成一致，以建立一个共同的前景（Vision） 特性说明了系统为用户提供的各项功能，它限定了系统的范围（Scope）,2.2 功能需求 用户需求,执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么 直接用户 间接用户 对所有的用户需求，都应该有充
9、分的问题域知识作为背景支持 特性 模糊、不清晰 多特性混杂 多逻辑混杂,2.2 功能需求 系统需求,用户对系统行为的期望，一系列的系统行为联系在一起可以帮助用户完成任务，满足业务需求 系统需求可以直接映射为系统行为，定义了系统中需要实现的功能，描述了开发人员需要实现什么 将用户需求转化为系统需求的过程是一个复杂的过程 首先需要分析问题领域及其特性，从中发现问题域和计算机系统的共享知识，建立系统的知识模型； 然后将用户需求部署到系统模型当中，即定义系列的系统行为，让它们联合起来实现用户需求，每一个系统行为即为一个系统需求。 该过程就是需求工程当中最为重要的需求分析活动，又称建模与分析活动。,2.
10、2 功能需求 从功能需求的层次性看需求开发,2.3 性能需求,速度（Speed），系统的响应时间，例如PR2.3.3-1。 PR2.3.3-1：所有的用户查询都必须在10秒内完成。 容量（Capacity），系统所能存储的数据量，例如PR2.3.3-2。 PR2.3.3-2：系统应该能够存储至少10万条销售记录。 吞吐量（Throughput），系统在连续的时间内完成的事务数量，例如PR2.3.3-3。 PR2.3.3-3：解释器每分钟应该至少解析5000条没有错误的语句。 负载（Load），系统可以承载的并发工作量，例如PR2.3.3-4。 PR2.3.3-4：系统应该允许200个用户同时进
11、行正常的工作。 实时性（Time-Critical），严格的实时要求，例如PR2.3.3-5。 PR2.3.3-5：监测到病人异常后，监控器必须在0.5秒内发出警报。,2.4质量属性,系统为了满足规定的及隐含的所有要求而需要具备的要素称为质量 质量属性是为了度量质量要素而选用的特征 质量模型就是能够为质量需求的描述和评价提供工作基础的特征集及特征之间的联系 质量属性的重要性 对设计的影响很大 对越复杂的系统越为重要 Robert19901 ：真实的现实系统中，在决定系统的成功或失败的因素中，满足非功能属性往往被满足功能性需求更为重要。,2.4质量属性 ISO/IEC 9126,2.4质量属性
12、ISO/IEC 9126,2.4质量属性 ISO/IEC 9126,2.4质量属性 ISO/IEC 9126,2.4质量属性 ISO/IEC 9126,2.4质量属性 ISO/IEC 9126,2.4质量属性 ISO/IEC 9126,2.4质量属性 质量属性的开发,用户并不能明确地提出他们对产品质量的期望 并不了解软件系统的开发过程，也就无从判断哪些质量属性会在怎样的程度上给设计带来多大的影响，也无法将他们对软件系统的质量要求细化成一组组的可量化的质量属性 需求工程师 质量属性大都是和功能需求联系在一起的，因此需要对照软件的质量属性检查每一项功能需求，尽力去判断质量属性存在的可能性 形容词和
13、副词通常意味着质量属性的存在 对于一些不和任何功能需求相联系的全局性质量属性，需求工程师要在碰到特定的实例时意识到它们的存在,2.5对外接口,解系统和其他系统之间的软硬件接口 接口的用途 接口的输入输出 数据格式 命令格式 异常处理要求 用户界面 利用专门的人机交互设计文档记录,2.6约束,总体上限制了开发人员设计和构建系统时的选择范围 系统开发及运行的环境。 包括目标机器、操作系统、网络环境、编程语言、数据库管理系统等。 问题域内的相关标准。 包括法律法规、行业协定、企业规章等。 商业规则。 用户在任务执行中的一些潜在规则也会限制开发人员设计和构建系统的选择范围,主要内容,需求的涵义 需求的
14、类型 需求工程的路线 优秀需求的特性 常见的需求错误,3. 需求工程的路线,问题分析和背景分析 发现问题比发现需求要简单的多 进行背景分析，以更好的理解用户的问题 问题分析 明确问题。 定义业务需求。 制定解决方案。 确定系统特性。,3. 需求工程的路线,需求获取 根据项目范围，确定问题域的范围 确定需求获取的源头 确定获取的主题和内容 选择需求获取的方法 围绕获取的内容，运用需求获取的方法，从源头获取需求 对获取过程中出现的分歧和问题，在项目前景的指导下进行解决 经过需求获取过程，可以得到获取的文档资料，其中以获取笔录为主,3. 需求工程的路线,需求分析 建立一个综合考虑了问题域特性和需求的
15、系统模型 根据系统模型将用户需求转化为系统需求 文档化和验证 产生规格说明 进行验证,主要内容,需求的涵义 需求的类型 需求工程的路线 优秀需求的特性 常见的需求错误,4. 优秀需求的特性,完整性 不需要做更多的扩展就可以充分的说明用户所需要的系统功能。 每一个需求的描述都应该包含开发人员设计和实现这项功能需要的所有信息 R2.5-1：系统应该允许被扩展。 （更好）R2.5-2：系统的调度算法应该允许被扩展。,4.优秀需求的特性,正确性 真实的反映用户的意图 必须请需求的提出者予以确认 精确性 描述仅包含必要的信息 简洁、清晰 （不好）R2.5-3：在实现之后，系统的调度算法应该允许被扩展。,
16、4.优秀需求的特性,可行性 由开发人员进行检查 需要进行一定的分析和研究，而不是单纯的凭借经验和直觉 必要的时候要通过开发原型来加以验证 必要性 满足用户的业务需求所必需的,4.优秀需求的特性,无歧义 每一项需求都应该有而且只能有一种解释 定义一个可以共同理解的词汇表（Glossary） 可验证 通过分析、检查、模拟或者测试等方法能够判断需求是否被满足 不可验证的需求往往是因为描述模糊或者过于抽象，所以在进行需求的描述时要 让需求具体化 小心形容词和副词的使用 避免程度词的使用,主要内容,需求的涵义 需求的类型 需求工程的路线 优秀需求的特性 常见的需求错误,5. 常见的需求定义错误,需求并没
17、有反映用户的真实需要 用户在表达自己的需要时，可能会在潜意识下进行一定的加工 发现问题背后的问题 在人际交流当中，信息会发生自然的衰减，甚至扭曲 检查和确认,5. 常见的需求定义错误,模糊和歧义的需求 无意中写出模糊和歧义的需求定义往往是因为选词造句不当 为项目中重要的词汇建立一个公共的可共同理解的词汇表 有意产生的模糊和歧义的需求定义往往是为了应付对需求持有不同立场的用户 在项目前景的指导下，促进用户之间的协商解决,5. 常见的需求定义错误,明显的信息遗漏 明显的信息遗漏，其主要原因在于项目的范围定义不当 加强对业务需求的处理 不明显的信息遗漏，往往是因为相关信息难以发现 该类问题是最难以解
18、决的问题，只能靠需求工程师的经验来加以避免,5. 常见的需求定义错误,不必要的需求 其一是用户将之作为和开发人员谈判的筹码 谈判技巧 其二是用户在交流当中，用户总是倾向于表达各种各样的需要 根据业务需求进行用户需求的过滤和选择 其三是需求开发人员“画蛇添足” 保持以用户为中心 不切实际的期望 用户并不掌握关于软件系统构建的相关技术知识，所以用户可能会提出一些已有软件技术无法实现的期望 软件开发者提供可行性、成本等足够的技术参考信息，帮助用户对其进行取舍和调整,5. 常见的需求定义错误,需求工程的示例,技术标书 研究型描述,实例分析（系统A招标书）,请说出下列需求的类型，是否存在问题？ 1、实现
19、各部门的公文流转无纸化、文档一体化、业务管理的规范化、自动化和网络化； 2、实现工作流程合理化、高效化，决策支持科学化、准确化； 3、统一办公流程、规范公文格式，加强信息交流和共享，提高工作效率。,实例分析（系统A 招标书）,请说出下列需求的类型，是否存在问题？ 先进性：软件系统采用三层B / S 系统结构，以“界面表示层逻辑处理层数据访问层”分层设计实现。采用国际上先进成熟的、厂商广泛支持的计算机技术、网络技术与软件技术对系统进行规划，保证系统整体架构在未来几年内都处于国际领先的地位。 安全性：软件系统具有较高的安全要求，系统必须具备充分的安全措施，包括具备严格的权限控制机制和完备的日志记录
20、，以确保信息安全。 可靠性：保证系统核心功能可以724小时连续运行； 规范性：系统必须遵循国家有关法律法规要求，符合国家有关标准要求以及关于信息系统建设的各项标准和规范。,实例分析（系统A 招标书）,请说出下列需求的类型，是否存在问题？ 收文管理应包括: 来文登记、拟办、领导审批、办理、归档、查询统计等功能。附件支持WORD 、PDF 、EXCEL 、HTML 等文档类型格式；需提供方便、灵活、直观的文件批示处理；对收文的处理全过程进行自动化管理、跟踪和记录；在收文处理的过程中，支持电子印章、电子签名或手写批注等功能。 来文登记：完成来文登记功能。登记来文基本信息（来文编号、来文标题、主题词、
21、来文单位、来文时间），还要对原文进行扫描处理，引入到公文库中。并可完成收文办文单打印功能。完成后启动收文流转流程。 拟办：查看公文的基本信息，原文内容。签录拟办意见，发送给领导审批。 领导审批：查看公文的基本信息，原文内容。签录批示意见，确定主办部门、协办部门。 办理：办理人根据领导批示办理，记录办理情况。 归档：对办理完结的来文归档，将来文信息、拟办意见、领导批示、办理情况等信息及来文扫描件发送到档案管理系统，档案科确认接收的文件，才属于己归档文件。 查询统计：提供按来文编号、来文标题、主题词、来文单位、来文时间等查询统计功能，要求查询统计结果可以打印。,实例分析（系统A 招标书）,请说出下
22、列需求的类型，是否存在问题？ 编程应遵循如下原则： 唯一性：每个实体及其属性必须有唯一的代码来确切地定义。 可扩充性：考虑到系统以后的发展，编号要留有余地。当增加新的实体时，可以直接在原代码的基础上加以扩充，扩充后不会引起代码体系的混乱，这样就避免了重新设计代码系统的麻烦。 通用性：凡国家、行业、地方对编码有统一标准和规定的，应尽量使用标准代码，代码适用范围越广越好。没有标准代码的，投标方设计的代码也应该统一，如代码长度与格式的统一。 便于记忆和识别：代码不但要具有一定的逻辑定义，也要尽量考虑用户的使用习惯，使代码便于记忆和识别，做到简单明了 简短性：在满足需要的前提下，代码要尽可能短。 编程
23、人员必须对所有代码进行严格自测。,实例分析（系统A 招标书）,请说出下列需求的类型，是否存在问题？ 验收投标方需提供以下文档： 软件需求分析报告 软件总体设计报告 软件操作手册 软件配置手册 软件试运行报告 应用软件介质,实例分析（系统A 招标书）,请说出下列需求的类型，是否存在问题？ 培训要求 投标人必须提供相应的应用软件技术和系统操作等方面的培训。投标人须在文件中提出全面、详细的培训课程以及时间表交给业主，并在合同签定后征得业主同意后实施。 投标人应提供面向系统管理员的应用软件系统结构、日常维护等方面的培训。 对于所有培训，投标人必须派出具有相应专业资格和实际工作经验的人员进行培训。 投标
24、人须提供详细的培训计划。 以上培训内容的培训费用均包含在投标报价内，项目采购人不再另行支付,实例分析（系统B需求规格说明）,请说出下列需求的类型，是否存在问题？ 2.1. 开发意图 1. 减少人力成本 2. 提高办公效率 3. 成本统计、查询 4. 历史信息查询 5. 支持WEB 操作,实例分析（系统B 需求规格说明）,请说出下列需求的类型，是否存在问题？ 2.3. 产品功能 2.3.1. 人员管理 对本公司的人力资源进行管理。 提供功能：新员工信息录入、信息修改（晋升、部门调动、休假、婚姻状况变更）、离职人员归档。 注）该操作需要具有人员管理权限的人才可以进行。 2.3.2. 业务管理 对本
25、公司的业务进行管理。 提供功能：新业务录入、现有业务变更（计划提前或延后、合同金额或付款方式变更、业务内容变更）、已完成的业务归档。 注）该操作需要具有业务管理权限的人才可以进行。,实例分析（系统B 需求规格说明）,请说出下列需求的类型，是否存在问题？ 2.4.1. 扩展性 要求结构设计良好，二次开发成本要求低于本次开发成本30% 能够简单的进行多语言版本改造。 2.4.2. 灵活性 支持主流浏览器：IE7,8, FireFox2.0, Google 浏览器。 2.4.3. 精度 金额相关：小数点后保留2 位有效数字； 时间相关：精确到秒； 传输过程中的精度：小数点后保留5 位有效数字。 2.
26、4.4. 响应要求 用户登陆： = 0.5 秒 页面跳转： = 2 秒 2.4.5. 安全性 系统管理员（admin）负责系统维护； 根据公司体制指定各部门负责人，并赋予相应的操作权限； 所有信息保存在MySQL 数据库中； 用户密码采用密文形式保存,实例分析（系统B 需求规格说明）,请说出下列需求的类型，是否存在问题？,实例分析（系统B 需求规格说明）,请说出下列需求的类型，是否存在问题？ 3.3.2. 人员信息变更 目的：修改员工信息。 功能：提供员工信息修改界面，并将修改后的信息保存进MySQL 数据库。 步骤： 1. 在界面上修改员工信息。 2. 操作者权限检查。 3. 操作成功，返回
27、人员管理界面； 操作失败，提示错误信息。 流程图：,实例分析（系统C）,请说出下列需求的类型，是否存在问题？ 4.1 业务现状与分析 单一客户经理渠道从“绿色通道”变成制约集团发展的瓶颈 其他营销服务界面缺乏有效识别集团客户的工具 目前公司缺少一套贯穿全省各级公司和各部门的统一业务调度系统来协助跨部门工作 各节点缺乏受理标准时限规范，内部资源调度无法快速响应， 客户经理在面对客户时无法进行服务时限承诺，降低了集团业务的客户满意 业务支撑平台不断增多，且均需要分散维护，服务质量难以保障,实例分析（系统C）,请说出下列需求的类型，是否存在问题？,本章小结,需求是人们对现实世界问题解决的期望 解系统通过共享知识和问题域进行互动，从而解决现实世界中的问题 具体的需求包括 功能需求、性能需求、质量属性、对外接口和约束 需求工程活动是依据需求的内涵与外延逐步展开的 书写的需求应该具有优秀的特性，尤其要避免出现常见的错误,
