软件需求工程N1.pptx

软件需求工程--需求概述Software Requirements Engineering ;第一章 软件需求概述;个人的需求之痛;例1;“当然是这样，我从没想过谁会莫名其妙地更改自己的姓名。我不记得你曾告诉我系统需要处理这样的事情，这就是为什么你们只能在改变婚姻状况对话框中才能进入更改姓名的对话框。”Phil 说。 M a r i a说：“我想你当然知道每个人只要愿意都可以随时合法更改他（她）们的姓名。但不管怎样，我们希望在下周五之前解决这个问题，否则， S p a r k l e将不能支付她的账单。你能在此前修改好这个错误吗？”;“这并不是我的错！我从来不知道你需要处理这种情况。我现在正忙着做一个新的性能检测系统，并且还要处理职员系统的一些需求变更请求” （传来翻阅稿纸的声音）。 “我还有别的事。我只可能在月底前修改好，一周内不行，很抱歉。下次若有类似情况，请早一些告诉我并把它们写下来。” “那我怎么跟S p a r k l e说呢？” M a r i a追问道，“如果她不能支付账单，那她只能挂帐了。”;“M a r i a，你要明白，这不是我的过错。”P h i l坚持道，“如果你一开始就告诉我，你要能随时改变某个人的名字，那这些都不会发生。因此你不能因我未猜出你的想法（需求）就责备我。” M a r i a不得不愤怒地屈从：“好吧，好吧，这种烦人的事使我恨死计算机系统了。等你修改好了，马上打电话告诉我，行吧？”;例2;但需求变更却越来越多。 为了节省时间，客户的业务人员不再向Steven申请变更，而是直接找程序员商量。 程序员疲于应付，往往直接改程序而不做任何记录，很多相关文档也忘记修改。 很快Steven就发现：需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样了”。;版本管理也出现了混乱，很多人违反配置管理规定，直接在测试环境中修改和编译程序。 但在进度压力下，他也只能佯装不知此事。但因频繁出现“改好的错误又重新出现”的问题，客户已经明确表示“失去了耐心”。 而这还只是噩梦的开始。 一个程序员未经许可擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。 ;虽然最终花费了整整3天的???间解决了这个问题，但客户却投诉了，表示“无法容忍这种低下的项目管理水平”。 更糟糕的是，因为担心系统中还隐含着其他类似的错误，客户高层对项目的质量也疑虑重重。 随后发生的事情让Steven更加为难客户的两个负责人对界面风格的看法不一致，并为此发生了激烈争执。; Steven知道如果发表意见可能会得罪其中一方，于是保持了沉默。 最终客户决定调整所有界面， Steven只好立刻动员大家抓紧时间修改。 可后来当听说因修改界面而造成了项目一周的延误后，客户方原来发生争执的两人这次却非常一致，同时气愤地质问Steven：“为什么你不早点告诉我们要延期！早知这样才不会让你改呢！” Steven很无耐，疑惑自己到底错在哪里了。 ;思考;对大多数人来说，若要建一幢2 0万美元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性。 然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”（L e ffingwell 1997）。 可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟（期望差异）—开发者开发的与用户所想得到的软件存在着巨大期望差异。;在软件工程中，所有的风险承担者（ s t a k e h o l d e r）都感兴趣的就是需求分析阶段。 这些风险承担者包括客户、用户、业务或需求分析员（负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人）、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。 这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。 因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用本书提供的有效的需求分析过程。; 项目失败因素分析;软件需求定义;软件需求定义;需求的层次和分类 ;需求的层次和分类;每个项目都有需求 ;不合格的需求;优秀需求具有的特性 ;高质量需求的好处;让用户积极参与需求收集过程能使产品更富有吸引力，而且能拥有忠实的客户关系。通过了解用户的任务需求而不仅仅局限于一些“华丽”的特性，你能避免在无用功能上白耗精力，并且用户的参与能弥补用户期望和开发者实际开发之间的“鸿沟（期望差异）”。 将选定系统的需求明确地分配到各软件子系统，强调采用产品工程的系统方法。这样能简化硬软件