03第三章需求工程精编版

《03第三章需求工程精编版》由会员分享，可在线阅读，更多相关《03第三章需求工程精编版（159页珍藏版）》请在金锄头文库上搜索。

1、2020/8/26,1,第三章 需求工程,2020/8/26,2,第三章 需求工程,3.1概述 3.2需求获取方法 3.3需求分析的任务与原则 3.4需求建模方法 3.5需求图形工具 3.6需求验证 3.7需求管理,2020/8/26,3,3.1概述3.1.1 软件需求定义3.1.2软件需求分类3.1.3需求规格说明3.1.4需求工程概念3.1.5需求工程过程,2020/8/26,4,5.2 软件需求的分类,软件需求的定义,2020/8/26,5,3.1概述,软件需求工程的目的是定义软件所需要解决的问题 。 软件需求是要把一个定义不足和模糊的问题转换为一个定义良好而准确的问题，进而找到解决问题

2、的方案。,2020/8/26,6,3.1概述,主要困难 ： 软件开发人员与用户双方固有的矛盾 需求具有易变性和难以表述性 需求错误的高频性和修复的高成本性,2020/8/26,7,软件开发的目标是什么？,开发高质量的软件； 在预定的时间和预算约束下完成； 软件要能够满足顾客的需求。,2020/8/26,8,但实际情况是什么样子？,调查报告的数字是这样的,51%,15%,34%,Standish Group 2004,Succeeded,Challenged,Failed,结论： 对用户需求的管理水平 是决定软件成败的重要原因,2020/8/26,9,案例分析1 “只有结婚后才可以修改姓名吗？”

3、,Phil开发了一套人力资源软件，有一天他接到了人力资源部Maria打来的电话,2020/8/26,10,“错误的需求”的扩散效应,2020/8/26,11,“错误的需求”的修复代价,“构建一个软件系统最困难的部分是确定构建什么在出错之后会严重影响随后实现的系统，并且在以后的修补是如此的困难”,2020/8/26,12,“错误的需求”所带来的后果,早期的需求错误可能造成 重新进行规格说明、设计、编码和测试 改变订单：告诉用户和操作员用一个修正后的版本来代替有缺陷的版本 纠正活动：消除由于不正确的系统错误造成的一切危害，可能涉及到赔偿客户损失以及重新运行系统等 报废：即使设计、代码和测试完成得很

4、好，由于它们是根据不正确的需求产生的，所以不得不被丢弃 收回有缺陷的软件产品以及相关的用户手册 技术人员为客户重新安装新软件所必须支付的服务成本,2020/8/26,13,根本原因是什么？,需求的鸿沟(期望差异)： 开发者开发的与用户所想得到 的软件存在着巨大期望差异。,2020/8/26,14,什么是“软件需求”,软件需求(Software Requirements)： 用户解决问题以达到特定目标所需的能力； 系统或系统构件要满足的合同、标准、规范或其他正式文档所需具备的能力；IEEE, 1997 指用户对软件的功能与性能需求,就是用户希望软件能够做什么事情,完成哪些功能，达到哪些性能等。

5、软件需求：以一种清晰、简洁、一致且无二义性的方式，描述用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，是在开发过程中对系统的约束。 需求通常用于表达“做什么”，而不描述“如何做”。,2020/8/26,15,“软件需求”的作用,“Requirement is the Basics of Quality” 充分理解现实中的业务问题，并作为软件设计的基础； 为软件项目的成本、时间、风险估计提供准确的依据； 减少开发工作量，避免将时间与资源浪费在设计与实现错误的需求上； 通过提供需求文档和需求基线，来有效的管理系统演化与变更； 作为顾客与开发团队之间正式合同的一部分； 为最终的验收测试提

6、供标准和依据；,2020/8/26,16,关于“需求”的例子,Course Registration System(学生选课系统) 某大学希望采用计算机管理学生的选课 学生可以在一个学期开始之前选择该学期开设的某些课程 老师可以使用选课系统获得选课学生的名单，并登记学生的课程学习成绩 学生不希望自己的学习成绩被他人查阅 (你可以补充吗？) 以下描述是否属于需求？为什么？ 系统通过JDBC与Oracle数据库CourseDB建立连接，并使用T-SQL语句从CourseOffering数据表中获得课程的开设信息。,2020/8/26,17,5.2 软件需求的分类,软件需求的分类,2020/8/26

7、,18,不同层次的软件需求,2020/8/26,19,1. 业务需求,业务需求(Business Requirements)：客户对于系统的高层次目标要求(high-level objectives) ，定义了项目的远景和范畴(vision and scope) 业务：属于哪类业务范畴？应完成什么功能？为何目的？ 客户：软件为谁服务？目标客户是谁？ 特性：区别于其他竞争产品的特性是什么？ 价值：价值体现在那些方面？ 优先级：功能特性的优先级次序是什么？ 例“图书资料管理系统”的业务需求 该系统使用计算机实现图书资料日常管理，提高工作效率和服务质量； 该系统可让用户在网络上查询与浏览电子资料，改

8、变原有的借阅模式； 由于版权的限制，某些电子资料只能浏览/打印，但不能下载。,2020/8/26,20,2. 用户需求(目标需求),用户需求(User Requirements)：从用户角度描述的系统功能需求与非功能需求，通常只涉及系统的外部行为而不涉及内部特性。 例用户可以通过Internet随时查询图书信息和个人借阅情况，并可以快速查找和浏览需要的电子资料； 功能需求用户通过Internet查询图书信息； 功能需求用户通过Internet浏览个人借阅情况； 功能需求用户通过Internet查找和浏览电子资料； 非功能需求随时、快速,2020/8/26,21,业务需求与用户需求的对比,针对C

9、ourse Registration System 业务需求 由于实行学分制管理，学校领导希望用计算机管理学生选课。 课程信息维护、选课管理、课程成绩登记和查询等业务全部由手工方式改为计算机应用。 用户需求 教务管理员希望能够增加、修改和删除学校的课程目录，并且设置各学期课程的开设信息。 学生希望能够在学期开始之前查询所有开设课程的详细信息，并能够通过校园网进行选课。 学生希望在选课期间系统能够24小时使用，系统使用方便快捷。,2020/8/26,22,3. 功能需求,功能需求(Functional Requirements, FR)：系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之

10、间的交互，不考虑系统内部的实现细节； 例 用户可从图书资料库中查询或者选择其中一个子集； 系统可提供适当的浏览器供用户阅读馆藏文献； 用户每次借阅图书应对应一个唯一的标识号，它被记录到用户的账户上；,2020/8/26,23,4. 非功能需求,非功能需求(Non-Functional Requirements, NFR)：从各个角度对系统的约束和限制，反映了客户对软件系统质量和性能(quality and performance)的额外要求，如响应时间、数据精度、可靠性等。 例 系统在20秒内响应所有的请求； 系统应该每周7天、每天24小时都可使用； 对一个没有经验的用户而言，经过2小时培训即

11、可使用系统所有功能。 注意：非功能需求隐含了对可选设计方案的一些关键影响 体系结构设计(e.g., 体系结构风格选择) 算法设计(e.g., 排序策略的选择),2020/8/26,24,非功能需求的度量,NFR：检验起来非常困难，一般采用一些可度量的特性进行描述。 例如： 即使对一个没有经验的用户，系统也应该很容易使用，且是用户错误降到最少； 修改为： 对一个没有经验的用户来说，经过2个小时的培训就应该使用系统的全部功能。在这样的培训之后，一个有经验的用户每天的出错平均数不应超过2次。,2020/8/26,25,NFR：检验起来非常困难，一般采用一些可度量的特性进行描述。,非功能需求的度量,2

12、020/8/26,26,一个例子：拼写检查器,业务需求：“用户能有效地纠正文档中的拼写错误” ； 用户需求：“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”； 功能性需求： 找到拼写错误的单词并以高亮度提示 显示提供替换词的对话框 实现整个文档范围的替换 非功能性需求： 正确的找到至少95%以上的错词并100%的加以正确替换 拼写检查的速度应至少达到5000词/秒。,2020/8/26,27,5. 约束条件,约束条件(Constraints)：系统设计和实现时必须满足的限制条件，对其进行权衡或调整是相当困难的，甚至是不可能的； 例如： 系统必须用C+或其他面向对象语言编写

13、； 系统用户接口需要采用图形化界面； 任取10秒，一个特定应用所消耗的可用计算能力平均不超过50%； 系统开发过程和交付文档需遵循GB/T 8567-2006标准； 通讯接口必须符合ISO七层架构。 来源：法规政策、硬件/资源限制、开发语言、等等。,2020/8/26,28,6. 业务规则,业务规则(Business Rule)：对某些功能的可执行性或内部执行逻辑的一些限定条件。 通常表达为“如果，那么”的形式 通常是一些容易发生变化的功能； 例如： 如果借书卡类型为“教师”，那么一次借阅的最大数量为8本； 如果订单金额大于10000元，那么该订单的折扣为10%； 如果采购单金额在10万到50

14、万之间，那么需要总经理审批；,2020/8/26,29,7. 外部接口需求,外部接口需求(External Interface Requirement)：描述系统与其所处的外部环境之间如何进行交互，包括： 用户接口需求(UI) 硬件接口需求 软件接口需求 通信接口需求 例如： “从读取信号” “给发送消息” “以读取文件” “能控制” “采用用户界面”,2020/8/26,30,关于需求的一些例子,系统必须有能力支持100个以上的并发用户，每个用户可以处理操作任务的任选组合，平均响应时间应该小于1秒，最大响应时间应小于5秒。 必须在对话窗口的中间显示错误警告，使用红色的、 14点加粗Arial

15、字体。 系统必须有能力存储平均操作连续100天所产生的事务。 系统应该在5分钟内计算出给定季度的总销售税。 系统应该在1分钟内从1000000条记录中检索出一个销售订单。 系统必须支持100个Windows工作站的并行访问。 系统可从各型号的modem上读取信号作为系统输入。,2020/8/26,31,需求规格说明,2020/8/26,32,3.1概述3.1.3需求规格说明,需求规格说明是指软件所应满足的全部要求，并用文档方式完整和精确描述。全部要求是指软件系统必须提供的功能和性能、约束条件和限制。,2020/8/26,33,5.2 软件需求的分类,好的需求 vs 坏的需求,2020/8/26

16、,34,好的需求应具备的特征,完整性：每一项需求都必须将所要实现的功能描述清楚 正确性：每一项需求都必须准确地陈述其要开发的功能； 可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的 必要性：每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来 划分优先级：给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量 无二义性：对所有需求说明的读者都只能有一个明确统一的解释 可验证性：检查一下每项需求是否能通过设计测试用例或其它验证方法，如用演示、检测等来确定产品是否确实按需求实现,2020/8/26,35,产生不合格需求的原因,无足够用户参与 “我不明白为什么要花那么多功夫收集需求” “与其与用户讨论浪费时间，不如写代码有意思” “我已经明白用户需求了” 用户需求的不断增加 若不断增加新需求，项目就越来越庞大以致超过其计划及预算范围 开发中不断延续的变更会使其整体结构日渐紊乱，补丁代码也使得整个程序难以理解和维护,2020/8/26,36,产生不合格需求的原因,模棱两可的需求 诸多读者对需求说明产生了不同的理解 单个读者能用不止一个方式