软件需求工程N1

软件需求工程--需求概述SoftwareRequirementsEngineering计算机科学与工程学院主讲：段丽英[e-mail]第一章软件需求概述需求的必要性软件需求的定义需求的层次和分类优秀需求具有的特性需求工程内容：需求开发与需求管理个人的需求之痛身份证的烦恼？？？签约之恼！！例1“喂，是Phil吗？我是人力资源部的Maria，我们在使用你编写的职员系统时遇到一个问题，一个职员想把她的名字改成SparkleStarlight而系统不允许，你能帮帮忙吗？”“她嫁给了一个姓Starlight的人吗？”Phil问。“不，她没有结婚，而仅仅是要更改她的名字，”Maria回答。“就是这问题，好像我们只能在婚姻状况改变时才能更改姓名。”“当然是这样，我从没想过谁会莫名其妙地更改自己的姓名。我不记得你曾告诉我系统需要处理这样的事情，这就是为什么你们只能在改变婚姻状况对话框中才能进入更改姓名的对话框。”Phil说。Maria说：“我想你当然知道每个人只要愿意都可以随时合法更改他（她）们的姓名。但不管怎样，我们希望在下周五之前解决这个问题，否则，Sparkle将不能支付她的账单。你能在此前修改好这个错误吗？”“这并不是我的错！我从来不知道你需要处理这种情况。我现在正忙着做一个新的性能检测系统，并且还要处理职员系统的一些需求变更请求”（传来翻阅稿纸的声音）。“我还有别的事。我只可能在月底前修改好，一周内不行，很抱歉。下次若有类似情况，请早一些告诉我并把它们写下来。”“那我怎么跟Sparkle说呢？”Maria追问道，“如果她不能支付账单，那她只能挂帐了。”“Maria，你要明白，这不是我的过错。”Phil坚持道，“如果你一开始就告诉我，你要能随时改变某个人的名字，那这些都不会发生。因此你不能因我未猜出你的想法（需求）就责备我。”Maria不得不愤怒地屈从：“好吧，好吧，这种烦人的事使我恨死计算机系统了。等你修改好了，马上打电话告诉我，行吧？”例2Steven刚出任项目经理，并承接了一个中型软件项目。公司再三叮咛他一定要尊重客户，充分满足客户需求。项目开始比较顺利，但进入到后期，客户频繁的需求变更带来很多额外工作。Steven动员大家加班，保持了项目的正常进度，客户相当满意。但需求变更却越来越多。为了节省时间，客户的业务人员不再向Steven申请变更，而是直接找程序员商量。程序员疲于应付，往往直接改程序而不做任何记录，很多相关文档也忘记修改。很快Steven就发现：需求、设计和代码无法保持一致，甚至没有人能说清楚现在系统“到底改成什么样了”。版本管理也出现了混乱，很多人违反配置管理规定，直接在测试环境中修改和编译程序。但在进度压力下，他也只能佯装不知此事。但因频繁出现“改好的错误又重新出现”的问题，客户已经明确表示“失去了耐心”。而这还只是噩梦的开始。一个程序员未经许可擅自修改了核心模块，造成系统运行异常缓慢，大量应用程序超时退出。虽然最终花费了整整3天的时间解决了这个问题，但客户却投诉了，表示“无法容忍这种低下的项目管理水平”。更糟糕的是，因为担心系统中还隐含着其他类似的错误，客户高层对项目的质量也疑虑重重。随后发生的事情让Steven更加为难客户的两个负责人对界面风格的看法不一致，并为此发生了激烈争执。Steven知道如果发表意见可能会得罪其中一方，于是保持了沉默。最终客户决定调整所有界面，Steven只好立刻动员大家抓紧时间修改。可后来当听说因修改界面而造成了项目一周的延误后，客户方原来发生争执的两人这次却非常一致，同时气愤地质问Steven：“为什么你不早点告诉我们要延期！早知这样才不会让你改呢！”Steven很无耐，疑惑自己到底错在哪里了。思考如果作为客户有过类似的经验，你一定知道：一个不能进行一项基本操作的软件产品是多么令人烦恼。尽管开发者最终会满足你的要求，你也不会感谢他。但从开发者角度来看，在整个系统已经完成后，用户再提出对功能的进一步要求是多么烦人的事。同时，修改系统的请求迫使你放下当前的项目，而且往往修改请求还要求你优先处理，也是令人很不愉快的。其实，在软件开发中遇到的许多问题，都是由于收集、编写、协商、修改产品需求过程中的手续和作法（方法）失误带来的。例如上面的Phil和Maria，出现的问题涉及到非正式信息的收集，未确定的或不明确的功能，未发现或未经交流的假设，不完善的需求文档，以及突发的需求变更过程。对大多数人来说，若要建一幢20万美元的房子，他一定会与建房者详细讨论各种细节，他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”（Leffingwell1997）。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟（期望差异）—开发者开发的与用户所想得到的软件存在着巨大期望差异。在软件工程中，所有的风险承担者（stakeholder）都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员（负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人）、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用本书提供的有效的需求分析过程。项目失败因素分析不完整的需求13.1%缺乏用户参与12.4%不切实际的用户期望9.9%需求变更频繁8.7%提供了不再需要的需求7.5%由此统计数据，与需求直接相关的因素累计权重51.6%。软件需求定义–１、软件需求是一个没有统一定义的名词．客户所定义的需求对开发者而言是一个较高层次的产品概念．而开发人员所说的需求对用户来说又像是详细设计了。–2、IEEE软件工程中定义：（1）用户解决问题或达到目标所需的条件或权能。（2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。（3）一种反映上面（1）或（2）所描述的条件或权能的文档说明。–3、另外一种通用的观点：认为需求是用户所需要的并能触发一个程序或系统开发工作的说明。软件需求定义软件需求定义它要解决的问题：它的意图和目的。定义问题，而不是解决方案定义系统，而不是项目区分正式和非正式部分避免重置保持每个需求定义的大小在合适的范围内是良好的做法并没有绝对清晰准确的需求存在，项目干系人必须保证理解的一致性。需求的层次和分类软件需求包括三个不同的层次：业务需求、用户需求、和功能需求。–1、业务需求（businessrequirement)描述了客户对系统、产品实现某些业务流程的高层次目标要求。–2、用户需求（userrequirement）描述了用户使用产品必须完成的任务。–3、功能需求（functionalrequirement）定义了开发人员必须实现的软件功能。–它们均应在不同位置体现在软件需求说明书中需求的层次和分类软件需求可以分为功能需求、非功能需求和设计约束三种类型。–1、功能需求定义了开发人员必须实现的软件功能，使用户能完成任务，从而满足业务需求。–2、非功能需求描述了系统展现给用户的行为和执行的操作等，包括外部界面细节、性能要求及质量属性。–3、设计约束是开发人员在软件产品设计和构造上的限制，产品必须遵从的标准、规范和合约。主要包括：非技术因素的技术选型、预期的软硬件环境和预期的使用环境。每个项目都有需求每个项目都应该有需求–开发软件系统最为困难的部分就是准确说明开发什么，最为困难的概念性工作是编写详细技术需求。不适当需求的一些风险–比如无足够用户参与、用户需求不断增加、模棱两可的需求、不必要的特性、过于精减等等，会导致开发不顺利甚至失败高质量需求的好处：–极大地减少开发后期和整个维护阶段的工作。不合格的需求1.无足够用户参与2.用户需求的不断增加3.模棱两可的需求4.不必要的特性5.过于精简的规格说明6.忽略了用户分类7.不准确的计划优秀需求具有的特性特性：–1、完整性–2、正确性–3、可行性–4、必要性–5、划分优先级–6、无二义性–7、可验证性高质量需求的好处最大的好处是在开发后期和整个维护阶段的重做的工作大大减少了。Boehm（1981）发现要改正在产品付诸应用后所发现的一个需求方面的缺陷比在需求阶段改正这个错误要多付出68倍的成本。近来很多研究表明这种错误导致成本放大因子可以高达200倍。收集需求能使开发小组更好地了解市场，而市场因素是任何项目成功的一个关键因素。在产品开发前了解这些比在遭到客户批评后才意识到要节约很多成本。让用户积极参与需求收集过程能使产品更富有吸引力，而且能拥有忠实的客户关系。通过了解用户的任务需求而不仅仅局限于一些“华丽”的特性，你能避免在无用功能上白耗精力，并且用户的参与能弥补用户期望和开发者实际开发之间的“鸿沟（期望差异）”。将选定系统的需求明确地分配到各软件子系统，强调采用产品工程的系统方法。这样能简化硬软件的集成，也能确保软硬件系统功能匹配适当。有效的变更控制和影响分析过程也能降低需求变更带来的负面影响。将需求编写成清晰、无二义性的文档将会极大地有利于系统测试，确保产品质量，以使所有风险承担者感到满意。需求的开发和管理整个需求范围可分为需求开发和需求管理需求开发进一步可分为：–1、问题获取（elicitation）–2、分析（analysis）–3、编写规格说明（specification）–4、验证（verification）需求开发和需求管理的区别小结1、软件需求的定义（有多种理解，以IEEE为主）。2、理解软件需求的层次以及各部分组成关系。3、优秀需求的特性和给工程实施带来的好处。4、需求工程中需求开发和需求管理关系和层次。思考：1、记录你在当前项目或以前项目中所遇到的与需求相关的问题。分析这些问题带来的影响及其产生的根本原因。2、结合一个你做过或了解过的项目，讨论需求与软件开发的关系。3、确定一个小组选题，作为本课程的实践项目及作业。客户的需求观干活不由东累死也无功！例子Contoso制药公司的高级管理长官Gerhard,会见Contoso公司的信息系统开发小组的新管理员Cynthia。“我们需要建立一套化学制品跟踪信息系统”，Gerhard说道。“该系统可以记录库房或某个实验室中已有的化学药品，这样，化学专家可以直接从楼下的某人那里拿到所需的药品，而不必再买一瓶新的。另外，卫生保健部门也得为联邦政府写些关于化学药品的使用报告。你们小组能在五个月内开发出该系统吗？”“我已经明白这个项目的重要性了，Gerhard”，Cynthia说，“但在我制定计划前，我们必须收集一些系统的需求。”Gerhard觉得很奇怪“你的意思是什么？我不是刚告诉你我的需求了吗？”“实际上，你只说明了整个项目的概念与目标，”Cynthia解释道，“这些高层次的业务需求并不能为我们提供足够的详细信息以确定究竟要开发什么样的软件，以及需要多长时间。我需要一些分析人员与一些知道系统使用要求的化学专家进行讨论，然后才能真正明白达到业务目标所需的各种功能和用户的要求。我们甚至并不需要开发一个新的软件系统，这样可节省许多钱。”Gerhard此前还从未遇到过与这位系统开发人员类似的看法。“那些化学专家都非常忙”他坚持道，“他们没有时间与你们详细讨论各种细节，你不能让你的手下的人说明要做的系统吗？”Cynthia尽力解释从使用新系统的用户处收集需求的合理性。“如果我们只是凭空猜想用户要求，结果不会令人满意。我们只是软件开发人员，而并非化学专家。我们并不能真正明白化学专家们需要这个化学制品跟踪系统做些什么。我曾经尝试过，未真正明白这些问题就匆忙开始编码，结果没有人对产品满意。“行了，行了，我们没有那么多时间”Gerhard坚持道。“我来告