5_introduction_to_requirement_engineeringnew

《5_introduction_to_requirement_engineeringnew》由会员上传分享，免费在线阅读，更多相关内容在教育资源-天天文库。

1、5需求工程概论前次课内容回顾：软件项目管理•项目的4P：People、Process、Product、Project；•软件项目管理的四个阶段；•可行性分析与估算•代码行方法、功能点方法；•项目进度计划与监控•网络图、甘特图；•项目风险管理•项目质量管理第三章需求工程软件工程第三章需求工程5需求工程概论王忠杰rainy@hit.edu.cn2008年3月13日5需求工程概论主要内容5.1软件需求的定义5.2需求的分类5.3需求工程5.4软件需求与SE其他要素的关系5.5与需求有关的风险第三章需求工程5.1软件需求的定义5需求工程概论[课堂讨论1]“我要一所大房子”•[课堂讨论1]每四人一组，通

2、过讨论来回答。•背景：我是你的建筑师，受雇佣为你建造一所大房子。•问题：你的需求是什么？•时间：2分钟•随机选择三组，每组选择一名代表口头陈述本组的讨论结果5需求工程概论什么是“需求”？我要一所大房子有很大的落地窗户阳光洒在地板上我要一所大房子也温暖了我的被子有很多很多的房间一个房间有最快的网路一个房间有很多的吉他一个房间有我漂亮的衣服一个房间住着朋友和他的爱人一个房间一个房间我们晚上不睡觉我也不知道该放些什么白天在床上思考小狗在屋里奔跑度过完美的一天5需求工程概论什么是“需求”？法国人、美国人和中国人被困在一个荒岛上，遇到了一个神仙…神仙说：“我可以满足你们每个人一个愿望。”法国人抢先说：“

3、我要回家！我要回家！”神仙说：“满足你的愿望。”于是把法国人送走了。美国人马上说：“我也要回家！我也要回家！”神仙说：“满足你的愿望。”于是美国人也被送走了。最后剩下中国人，神仙问：“你有什么愿望？”中国人说：“他们都走了，留下我怪寂寞的，把他们叫回来吧。”于是法国人和美国人又回来了...5需求工程概论软件开发的目标是什么？•开发高质量的软件；•在预定的时间和预算约束下完成；•软件要能够满足顾客的需求。5需求工程概论但实际情况是什么样子？•调查报告的数字是这样的…用户参与程度高：16%SucceededSucceeded用户高层的支持：14%对需求的清晰陈述：12%缺乏用户参与：13%Chal

4、lengedChallenged需求规格说明不完整：12%需求频繁的发生变化：12%FailedFailed结论：对用户需求的管理水平°StandishGroup2004是决定软件成败的重要原因5需求工程概论[案例分析1]“只有结婚后才可以修改姓名吗？”•Phil开发了一套人力资源软件，有一天他接到了人力资源部Maria打来的电话…Maria一个同事想把自己的名字改为SparkleStarlight，但系统不允许，能帮忙吗？Phil她嫁给了一个姓Starlight的人吗？Maria不，她并没有结婚，她只是想改名字而已；Phil系统只支持在改变婚姻状况时才可以改名字。Maria可是每个人只要愿意

5、就可以随时改变自己的名字啊。Phil这并不是我的错！在开发系统之前，你从来没有向我提起过有这种需求！Maria不管如何，请尽快把这个功能修改完毕，否则Sparkle将无法支付她的银行帐单。Phil如果你一开始就告诉我你要能随时改变某个人的名字，那这些就都不会发生！……5需求工程概论“错误的需求”所带来的后果•早期的需求错误可能造成•重新规格说明、设计、编码和测试•改变订单：告诉用户和操作员用一个修正后的版本来代替有缺陷的版本•纠正活动：消除由于不正确的系统错误造成的一切危害，可能涉及到赔偿客户损失以及重新运行系统等•报废：即使设计、代码和测试完成得很好，由于它们是根据不正确的需求产生的，所以不

6、得不被丢弃•收回有缺陷的软件产品以及相关的用户手册•技术人员为客户重新安装新软件所必须支付的服务成本5需求工程概论“错误的需求”的扩散效应问题问题正确的需求错误的需求正确的设计错误的设计基于“错误的需求”的设计正确的编码错误的编码基于“错误的基于“错误的需求”的编码设计”的编码5需求工程概论“错误的需求”的修复代价需求分析.1~.2.5设计1编码“构建一个软件系统最困难的部分是确定单元测试2构建什么…在出错之后会严重影响随后5集成测试实现的系统，并且在以后的修补种如此的困难…”运行与维护205需求工程概论根本原因是什么？需求的鸿沟(期望差异)：开发者开发的与用户所想得到的软件存在着巨大期望差异

7、。5需求工程概论“软件需求”的作用•“RequirementistheBasicsofQuality”•充分理解现实中的业务问题，并作为软件设计的基础；•为软件项目的成本、时间、风险估计提供准确的依据；•减少开发工作量，避免将时间与资源浪费在设计与实现错误的需求上；•通过提供需求文档和需求基线，来有效的管理系统演化与变更；•作为顾客与开发团队之间正式合同的一部分；•为最终的验收测试提供标准和依据；