03第三章需求工程

2019/8/71第三章需求工程主讲：任向民2019/8/72第三章需求工程3.1概述3.2需求获取方法3.3需求分析的任务与原则3.4需求建模方法3.5需求图形工具3.6需求验证3.7需求管理2019/8/733.1概述3.1.1软件需求定义3.1.2软件需求分类3.1.3需求规格说明3.1.4需求工程概念3.1.5需求工程过程2019/8/745.2软件需求的分类软件需求的定义2019/8/753.1概述•软件需求工程的目的是定义软件所需要解决的问题。•软件需求是要把一个定义不足和模糊的问题转换为一个定义良好而准确的问题，进而找到解决问题的方案。2019/8/763.1概述主要困难：1.软件开发人员与用户双方固有的矛盾2.需求具有易变性和难以表述性3.需求错误的高频性和修复的高成本性2019/8/77软件开发的目标是什么？•开发高质量的软件；•在预定的时间和预算约束下完成；•软件要能够满足顾客的需求。2019/8/78但实际情况是什么样子？•调查报告的数字是这样的…StandishGroup2004SucceededChallengedFailed用户参与程度高：16%用户高层的支持：14%对需求的清晰陈述：12%缺乏用户参与：13%需求规格说明不完整：12%需求频繁的发生变化：12%结论：对用户需求的管理水平是决定软件成败的重要原因2019/8/79[案例分析1]“只有结婚后才可以修改姓名吗？”•Phil开发了一套人力资源软件，有一天他接到了人力资源部Maria打来的电话…Maria一个同事想把自己名字改为SparkleStarlight，但系统不允许，能帮忙吗？Phil她嫁给了一个姓Starlight的人吗？Maria不，她并没有结婚，她只是想改名字而已；Phil系统只支持在改变婚姻状况时才可以改名字。Maria可是每个人只要愿意就可以随时改变自己的名字啊。Phil这并不是我的错！在开发系统之前，你从来没有向我提起过有这种需求！Maria不管如何，请尽快把这个功能修改完毕，否则Sparkle无法支付她的银行帐单。Phil如果你一开始就告诉我你想随时改变某人的名字，那这些就都不会发生！……2019/8/710“错误的需求”的扩散效应问题正确的需求错误的需求正确的设计基于“错误的需求”的设计错误的设计基于“错误的设计”的编码正确的编码错误的编码基于“错误的需求”的编码2019/8/711“错误的需求”的修复代价“构建一个软件系统最困难的部分是确定构建什么…在出错之后会严重影响随后实现的系统，并且在以后的修补是如此的困难…”2019/8/713根本原因是什么？需求的鸿沟(期望差异)：开发者开发的与用户所想得到的软件存在着巨大期望差异。2019/8/714什么是“软件需求”•软件需求(SoftwareRequirements)：–用户解决问题以达到特定目标所需的能力；–系统或系统构件要满足的合同、标准、规范或其他正式文档所需具备的能力；——IEEE,1997–指用户对软件的功能与性能需求,就是用户希望软件能够做什么事情,完成哪些功能，达到哪些性能等。•软件需求：以一种清晰、简洁、一致且无二义性的方式，描述用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，是在开发过程中对系统的约束。•需求通常用于表达“做什么”，而不描述“如何做”。2019/8/716关于“需求”的例子•CourseRegistrationSystem(学生选课系统)–某大学希望采用计算机管理学生的选课–学生可以在一个学期开始之前选择该学期开设的某些课程–老师可以使用选课系统获得选课学生的名单，并登记学生的课程学习成绩–学生不希望自己的学习成绩被他人查阅–……(你可以补充吗？)•以下描述是否属于需求？为什么？–系统通过JDBC与Oracle数据库CourseDB建立连接，并使用T-SQL语句从CourseOffering数据表中获得课程的开设信息。2019/8/7175.2软件需求的分类软件需求的分类2019/8/718不同层次的软件需求业务需求项目视图与范围文档业务规则用例文档功能需求软件需求规格说明外部接口需求用户需求功能性需求非功能性需求约束条件非功能需求2019/8/7191.业务需求•业务需求(BusinessRequirements)：客户对于系统的高层次目标要求(high-levelobjectives)，定义了项目的远景和范畴(visionandscope)–业务：属于哪类业务范畴？应完成什么功能？为何目的？–客户：软件为谁服务？目标客户是谁？–特性：区别于其他竞争产品的特性是什么？–价值：价值体现在那些方面？–优先级：功能特性的优先级次序是什么？•[例]“图书资料管理系统”的业务需求–该系统使用计算机实现图书资料日常管理，提高工作效率和服务质量；–该系统可让用户在网络上查询与浏览电子资料，改变原有的借阅模式；–由于版权的限制，某些电子资料只能浏览/打印，但不能下载。2019/8/7202.用户需求(目标需求)•用户需求(UserRequirements)：从用户角度描述的系统功能需求与非功能需求，通常只涉及系统的外部行为而不涉及内部特性。•[例]用户可以通过Internet随时查询图书信息和个人借阅情况，并可以快速查找和浏览需要的电子资料；–[功能需求]用户通过Internet查询图书信息；–[功能需求]用户通过Internet浏览个人借阅情况；–[功能需求]用户通过Internet查找和浏览电子资料；–[非功能需求]随时、快速2019/8/721业务需求与用户需求的对比•针对CourseRegistrationSystem•业务需求–由于实行学分制管理，学校领导希望用计算机管理学生选课。–课程信息维护、选课管理、课程成绩登记和查询等业务全部由手工方式改为计算机应用。•用户需求–教务管理员希望能够增加、修改和删除学校的课程目录，并且设置各学期课程的开设信息。–学生希望能够在学期开始之前查询所有开设课程的详细信息，并能够通过校园网进行选课。–学生希望在选课期间系统能够24小时使用，系统使用方便快捷。2019/8/7223.功能需求•功能需求(FunctionalRequirements,FR)：系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，不考虑系统内部的实现细节；•[例]–用户可从图书资料库中查询或者选择其中一个子集；–系统可提供适当的浏览器供用户阅读馆藏文献；–用户每次借阅图书应对应一个唯一的标识号，它被记录到用户的账户上；2019/8/7234.非功能需求•非功能需求(Non-FunctionalRequirements,NFR)：从各个角度对系统的约束和限制，反映了客户对软件系统质量和性能(qualityandperformance)的额外要求，如响应时间、数据精度、可靠性等。•[例]–系统在20秒内响应所有的请求；–系统应该每周7天、每天24小时都可使用；–对一个没有经验的用户而言，经过2小时培训即可使用系统所有功能。•注意：非功能需求隐含了对可选设计方案的一些关键影响–体系结构设计(e.g.,体系结构风格选择)–算法设计(e.g.,排序策略的选择)2019/8/724非功能需求的度量•NFR：检验起来非常困难，一般采用一些可度量的特性进行描述。•例如：–即使对一个没有经验的用户，系统也应该很容易使用，且是用户错误降到最少；•修改为：–对一个没有经验的用户来说，经过2个小时的培训就应该使用系统的全部功能。在这样的培训之后，一个有经验的用户每天的出错平均数不应超过2次。2019/8/725•NFR：检验起来非常困难，一般采用一些可度量的特性进行描述。非功能需求的度量非功能特性度量指标速度每秒处理的事务用户的响应时间屏幕的刷新速度存储空间字节数RAM芯片数可用性培训时间帮助页面数可靠性平均失败时间系统无效的概率失败发生率容错性失败后的重启次数事件引起失败的比例失败时数据崩溃的可能性2019/8/726一个例子：拼写检查器•业务需求：“用户能有效地纠正文档中的拼写错误”；•用户需求：“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”；•功能性需求：–找到拼写错误的单词并以高亮度提示–显示提供替换词的对话框–实现整个文档范围的替换•非功能性需求：–正确的找到至少95%以上的错词并100%的加以正确替换–拼写检查的速度应至少达到5000词/秒。2019/8/7275.约束条件•约束条件(Constraints)：系统设计和实现时必须满足的限制条件，对其进行权衡或调整是相当困难的，甚至是不可能的；•例如：–系统必须用C++或其他面向对象语言编写；–系统用户接口需要采用图形化界面；–任取10秒，一个特定应用所消耗的可用计算能力平均不超过50%；–系统开发过程和交付文档需遵循GB/T8567-2006标准；–通讯接口必须符合ISO七层架构。•来源：法规政策、硬件/资源限制、开发语言、等等。2019/8/7286.业务规则•业务规则(BusinessRule)：对某些功能的可执行性或内部执行逻辑的一些限定条件。–通常表达为“如果…，那么…”的形式–通常是一些容易发生变化的功能；•例如：–如果借书卡类型为“教师”，那么一次借阅的最大数量为8本；–如果订单金额大于10000元，那么该订单的折扣为10%；–如果采购单金额在10万到50万之间，那么需要总经理审批；2019/8/7297.外部接口需求•外部接口需求(ExternalInterfaceRequirement)：描述系统与其所处的外部环境之间如何进行交互，包括：–用户接口需求(UI)–硬件接口需求–软件接口需求–通信接口需求•例如：–“从某些设备读取信号”–“给一些其它系统发送消息”–“以某种格式读取文件”–“能控制一些硬件”–“采用某种类型的用户界面”2019/8/730关于需求的一些例子•系统必须有能力支持100个以上的并发用户，每个用户可以处理操作任务的任选组合，平均响应时间应该小于1秒，最大响应时间应小于5秒。•必须在对话窗口的中间显示错误警告，使用红色的、14点加粗Arial字体。•系统必须有能力存储平均操作连续100天所产生的事务。•系统应该在5分钟内计算出给定季度的总销售税。•系统应该在1分钟内从1000000条记录中检索出一个销售订单。•系统必须支持100个Windows工作站的并行访问。•系统可从各型号的modem上读取信号作为系统输入。2019/8/731需求规格说明2019/8/7323.1概述3.1.3需求规格说明需求规格说明是指软件所应满足的全部要求，并用文档方式完整和精确描述。全部要求是指软件系统必须提供的功能和性能、约束条件和限制。2019/8/7335.2软件需求的分类好的需求vs坏的需求2019/8/734好的需求应具备的特征•完整性：每一项需求都必须将所要实现的功能描述清楚•正确性：每一项需求都必须准确地陈述其要开发的功能；•可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的•必要性：每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来•划分优先级：给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量•无二义性：对所有需求说明的读者都只能有一个明确统一的解释•可验证性：检查一下每项需求是否能通过设计测试用例或其它验证方法，如用演示、检测等来确定产品是否确实按需求实现2019/8/735产生不合格需求的原因•无足够用户参与——“我不明白为什么要花那么多功夫收集需求”——“与其与用户讨论浪费时间，不如写代码有意思”——“我已经明白用户需求了”•用户需求的不断增加——若不断增加新需求，项目就越来越庞大以致超过其计划及预算范围——开发中不断延续的变更会使其整体结构日渐紊乱，补丁代码也使得整个程序难以理解和维护2019/8/736产生不合格需求的原因•模棱两可的需求——诸多读者对需求说明产生了不同的理解——单个读者能用不止一个方式来