5需求工程概论

5需求工程概论前次课内容回顾：软件项目管理•项目的4P：People、Process、Product、Project；•软件项目管理的四个阶段；•可行性分析与估算•代码行方法、功能点方法；•项目进度计划与监控•网络图、甘特图；•项目风险管理•项目质量管理5需求工程概论主要内容5.1软件需求的定义5.2需求的分类5.3需求工程5.4软件需求与SE其他要素的关系5.5与需求有关的风险第三章需求工程5.1软件需求的定义5需求工程概论[课堂讨论1]“我要一所大房子”•[课堂讨论1]每四人一组，通过讨论来回答。•背景：我是你的建筑师，受雇佣为你建造一所大房子。•问题：你的需求是什么？•时间：2分钟•随机选择三组，每组选择一名代表口头陈述本组的讨论结果5需求工程概论什么是“需求”？我要一所大房子有很大的落地窗户阳光洒在地板上也温暖了我的被子我们晚上不睡觉白天在床上思考小狗在屋里奔跑度过完美的一天我要一所大房子有很多很多的房间一个房间有最快的网路一个房间有很多的吉他一个房间有我漂亮的衣服一个房间住着朋友和他的爱人一个房间一个房间我也不知道该放些什么5需求工程概论什么是“需求”？法国人、美国人和中国人被困在一个荒岛上，遇到了一个神仙…神仙说：“我可以满足你们每个人一个愿望。”法国人抢先说：“我要回家！我要回家！”神仙说：“满足你的愿望。”于是把法国人送走了。美国人马上说：“我也要回家！我也要回家！”神仙说：“满足你的愿望。”于是美国人也被送走了。昀后剩下中国人，神仙问：“你有什么愿望？”中国人说：“他们都走了，留下我怪寂寞的，把他们叫回来吧。”于是法国人和美国人又回来了...5需求工程概论软件开发的目标是什么？•开发高质量的软件；•在预定的时间和预算约束下完成；•软件要能够满足顾客的需求。5需求工程概论但实际情况是什么样子？•调查报告的数字是这样的…ƒStandishGroup2004SucceededSucceededChallengedChallengedFailedFailed用户参与程度高：16%用户高层的支持：14%对需求的清晰陈述：12%缺乏用户参与：13%需求规格说明不完整：12%需求频繁的发生变化：12%结论：结论：对用户需求的管理水平对用户需求的管理水平是决定软件成败的重要原因是决定软件成败的重要原因5需求工程概论[案例分析1]“只有结婚后才可以修改姓名吗？”•Phil开发了一套人力资源软件，有一天他接到了人力资源部Maria打来的电话………如果你一开始就告诉我你要能随时改变某个人的名字，那这些就都不会发生！Phil不管如何，请尽快把这个功能修改完毕，否则Sparkle将无法支付她的银行帐单。Maria这并不是我的错！在开发系统之前，你从来没有向我提起过有这种需求！Phil可是每个人只要愿意就可以随时改变自己的名字啊。Maria系统只支持在改变婚姻状况时才可以改名字。Phil不，她并没有结婚，她只是想改名字而已；Maria她嫁给了一个姓Starlight的人吗？Phil一个同事想把自己的名字改为SparkleStarlight，但系统不允许，能帮忙吗？Maria5需求工程概论“错误的需求”所带来的后果•早期的需求错误可能造成•重新规格说明、设计、编码和测试•改变订单：告诉用户和操作员用一个修正后的版本来代替有缺陷的版本•纠正活动：消除由于不正确的系统错误造成的一切危害，可能涉及到赔偿客户损失以及重新运行系统等•报废：即使设计、代码和测试完成得很好，由于它们是根据不正确的需求产生的，所以不得不被丢弃•收回有缺陷的软件产品以及相关的用户手册•技术人员为客户重新安装新软件所必须支付的服务成本5需求工程概论“错误的需求”的扩散效应问题问题正确的需求错误的需求正确的设计基于“错误的需求”的设计错误的设计基于“错误的设计”的编码正确的编码错误的编码基于“错误的需求”的编码5需求工程概论“错误的需求”的修复代价.1~.2.512520需求分析设计编码单元测试集成测试运行与维护“构建一个软件系统最困难的部分是确定构建什么…在出错之后会严重影响随后实现的系统，并且在以后的修补种如此的困难…”5需求工程概论根本原因是什么？需求的鸿沟(期望差异)：开发者开发的与用户所想得到的软件存在着巨大期望差异。5需求工程概论“软件需求”的作用•“RequirementistheBasicsofQuality”•充分理解现实中的业务问题，并作为软件设计的基础；•为软件项目的成本、时间、风险估计提供准确的依据；•减少开发工作量，避免将时间与资源浪费在设计与实现错误的需求上；•通过提供需求文档和需求基线，来有效的管理系统演化与变更；•作为顾客与开发团队之间正式合同的一部分；•为昀终的验收测试提供标准和依据；5需求工程概论什么是“软件需求”•软件需求(SoftwareRequirements)：•用户解决问题以达到特定目标所需的能力；•系统或系统构件要满足的合同、标准、规范或其他正式文档所需具备的能力；——IEEE,1997•软件需求：以一种清晰、简洁、一致且无二义性的方式，描述用户对目标软件系统在功能、行为、性能、设计约束等方面的期望，是在开发过程中对系统的约束。•需求通常用于表达“做什么”，而不描述“如何做”。5需求工程概论关于“需求”的例子•CourseRegistrationSystem(学生选课系统)•某大学希望采用计算机管理学生的选课•学生可以在一个学期开始之前选择该学期开设的某些课程•老师可以使用选课系统获得选课学生的名单，并登记学生的课程学习成绩•学生不希望自己的学习成绩被他人查阅•……(你可以补充吗？)•以下描述是否属于需求？为什么？•系统通过JDBC与Oracle数据库CourseDB建立连接，并从CourseOffering数据表中获得课程的开设信息。第三章需求工程5.2软件需求的分类5需求工程概论不同层次的软件需求业务需求项目视图与范围文档业务规则用例文档功能需求系统需求软件需求规格说明外部接口需求用户需求功能性需求非功能性需求约束条件非功能需求5需求工程概论5.2.1业务需求•业务需求(BusinessRequirements)：客户对于系统的高层次目标要求，定义了项目的远景和范畴•业务：属于哪类业务范畴？应完成什么功能？为何目的？•客户：软件为谁服务？目标客户是谁？•特性：区别于其他竞争产品的特性是什么？•价值：价值体现在那些方面？•优先级：功能特性的优先级次序是什么？•[例]“图书资料管理系统”的业务需求•该系统使用计算机实现图书资料的日常管理，提高工作效率和服务质量；•该系统可让用户在网络上查询与浏览电子资料，改变原有的借阅模式；•由于版权的限制，某些电子资料只能浏览/打印，但不能下载。5需求工程概论5.2.2用户需求•用户需求(UserRequirements)：从用户角度描述的系统功能需求与非功能需求，通常只涉及系统的外部行为而不涉及内部特性。•[例]用户可以通过Internet随时查询图书信息和个人借阅情况，并可以快速查找和浏览需要的电子资料；•[功能需求]用户通过Internet查询图书信息；•[功能需求]用户通过Internet浏览个人借阅情况；•[功能需求]用户通过Internet查找和浏览电子资料；•[非功能需求]随时、快速5需求工程概论业务需求与用户需求的对比•CourseRegistrationSystem•业务需求•由于实行学分制管理，学校领导希望用计算机管理学生选课。•课程信息维护、选课管理、课程成绩登记和查询等业务全部由手工方式改为计算机应用。•用户需求•教务管理员希望能够增加、修改和删除学校的课程目录，并且设置各学期课程的开设信息。•学生希望能够在学期开始之前查询所有开设课程的详细信息，并能够通过校园网进行选课。•学生希望在选课期间系统能够24小时使用，系统使用方便快捷。5需求工程概论5.2.3系统需求•系统需求(SystemRequirement)是对用户需求的扩展，添加了许多细节内容，解释如何让系统来满足用户需求；•“系统需求”将作为软件设计的起点，从需求阶段过渡到设计阶段；•系统需求通常采用图形化的模型形式加以刻画。•例如：•描述功能的输入输出信息；•描述功能的前置条件和后置条件；5需求工程概论5.2.4功能需求•功能需求(FunctionalRequirements,FR)：系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，不考虑系统内部的实现细节；•[例]•用户可从图书资料库中查询或者选择其中一个子集；•系统可提供适当的浏览器供用户阅读馆藏文献；•用户每次借阅图书应对应一个唯一的标识号，它被记录到用户的账户上；5需求工程概论5.2.5非功能需求•非功能需求(Non-FunctionalRequirements,NFR)：从各个角度对系统的约束和限制，反映了客户对软件系统质量和特性的额外要求，如响应时间、数据精度、可靠性等。•[例]•系统在20秒内响应所有的请求；•系统应该每周7天、每天24小时都可使用；•对一个没有经验的用户而言，经过2小时培训即可使用系统的所有功能。5需求工程概论非功能需求的度量•NFR：检验起来非常困难，一般采用一些可度量的特性进行描述。•例如：•即使对一个没有经验的用户，系统也应该很容易使用，且是用户错误降到昀少；•修改为：•对一个没有经验的用户来说，经过2个小时的培训就应该使用系统的全部功能。在这样的培训之后，一个有经验的用户每天的出错平均数不应超过2次。5需求工程概论•NFR：检验起来非常困难，一般采用一些可度量的特性进行描述。非功能需求的度量失败后的重启次数事件引起失败的比例失败时数据崩溃的可能性容错性平均失败时间系统无效的概率失败发生率可靠性培训时间帮助页面数可用性字节数RAM芯片数存储空间每秒处理的事务用户的响应时间屏幕的刷新速度速度度量指标非功能特性5需求工程概论5.2.6约束条件•约束条件(Constraints)：系统设计和实现时必须满足的限制条件，对其进行权衡或调整是相当困难的，甚至是不可能的；•例如：•系统必须用C++或其他面向对象语言编写；•系统用户接口需要菜单；•任取10秒，一个特定应用所消耗的可用计算能力平均不超过50%；•系统开发过程和交付文档需遵循GB/T8567-2006标准；•来源：法规政策、硬件/资源限制、开发语言、等等。5需求工程概论一些例子•系统必须有能力支持100个以上的并发用户，每个用户可以处理操作任务的任选组合，平均响应时间应该小于1秒，昀大响应时间应小于5秒。•必须在对话窗口的中间显示错误警告，使用红色的、14点加粗Arial字体。•系统必须有能力存储平均操作连续100天所产生的事务。•通讯接口必须符合ISO七层架构。•系统应该在5分钟内计算出给定季度的总销售税。•系统应该在1分钟内从1000000条记录中检索出一个销售订单。•系统必须支持100个Windows工作站的并行访问。5需求工程概论5.2.7业务规则•业务规则(BusinessRule)：对某些功能的可执行性或内部执行逻辑的一些限定条件。•通常表达为“如果…，那么…”的形式•例如：•如果借书卡类型为“教师”，那么一次借阅的昀大数量为8本；•如果订单金额大于10000元，那么该订单的折扣为10%；•如果采购单金额在10万到50万之间，那么需要总经理审批；5需求工程概论5.2.8外部接口需求•外部接口需求(ExternalInterfaceRequirement)：描述系统与其所处的环境之间如何进行交互，包括：•用户接口需求(UI)•硬件接口需求•软件接口需求•通信接口需求•例如：•“从某些设备读取信号”•“给一些其它系统发送消息”•“以某种格式读取文件”•“能控制一些硬件”•“采用某种类型的用户界面”5需求工程概论一个例子：拼写检查器•业务需求：“用户能有效地纠正文档中的拼写错误”；•用户需求：“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”；•功能性需求：•找到并高亮度提示错词的操作•显示提供