软件需求分析(经典中的经典)(171).doc

《软件需求分析(经典中的经典)(171).doc》由会员分享，可在线阅读，更多相关《软件需求分析(经典中的经典)(171).doc（7页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、下载 第一局部 软件需求： 是什么和为什么 第1 章 根本的软件需求 “喂，是Phil吗？我是人力资源部的 Maria，我们在使用你编写的职员系统时遇到一 个问题，一个职员想把她的名字改成Sparkle Starlight，而系统不允许，你能帮帮助吗？ “她嫁给了一个姓 Starlight 的人吗？ Phil问道。 “不，她没有结婚，而仅仅是要更改她的名字， M a r i a 答复。“就是这问题，好 像我们只能在婚姻状况改变时才能更改姓名。 “当然是这样，我从没想过谁会莫名其妙地更改自己的姓名。我不记得你曾告诉 我系统需要处理这样的事情，这就是为什么你们只能在改变婚姻状况对话框中才能 进入更

2、改姓名的对话框。 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追问道，

3、“如果她不能支付账单，那她只能挂 帐了。 “ M a r i a ，你要明白，这不是我的过错。 P h i l 坚持道，“如果你一开始就告诉我， 你要能随时改变某个人的名字，那这些都不会发生。因此你不能因我未猜出你的想 法需求就责备我。 M a r i a不得不愤怒地屈从：“好吧，好吧，这种烦人的事使我恨死计算机系统了。 等你修改好了，马上打 告诉我，行吧？ 如果作为客户有过类似的经验，你一定知道：一个不能进行一项根本操作的软件产品是多么令人烦恼。尽管开发者最终会满足你的要求，你也不会感谢他。但从开发者角度来看，在整个系统已经完成后，用户再提出对功能的进一步要求是多么烦人的事。同时，修改系统的

4、请求迫使你放下当前的工程，而且往往修改请求还要求你优先处理，也是令人很不愉快的。 其实，在软件开发中遇到的许多问题，都是由于收集、编写、协商、修改产品需求过程中的手续和作法方法失误带来的。例如上面的 P h i l 和 M a r i a，出现的问题涉及到非正式信息的收集，未确定的或不明确的功能，未发现或未经交流的假设，不完善的需求文档，以及突发的需求变更过程。 对大多数人来说，假设要建一幢 2 0 万美元的房子，他一定会与建房者详细讨论各种细节， 2 第一局部 软件需求：是什么和为什么 下载 他们都明白完工以后的修改会造成损失，以及变更细节的危害性。然而，涉及到软件开发， 人们却变得“大大咧

5、咧起来。软件工程中百分之四十至百分之六十的问题都是在需求分析 阶段埋下的“祸根 L e ffingwell 1997 。可许多组织仍在那些根本的工程功能上采用一些不 合标准的方法，这样导致的后果便是一条鸿沟期望差异 开发者开发的与用户所想得 到的软件存在着巨大期望差异。 在软件工程中，所有的风险承当者 stakeholder都感兴趣的就是需求分析阶段。这些风 险承当者包括客户、用户、业务或需求分析员负责收集客户需求并编写文档，以及负责客 户与开发机构之间联系沟通的人、开发人员、测试人员、用户文档编写者、工程管理者和客 户管理者。这局部工作假设处理好了，能开发出很出色的产品，同时会使客户感到满意

6、，开发 者也倍感满足、充实。假设处理不好，那么会导致误解、挫折、障碍以及潜在质量和业务价值上 的威胁。因为需求分析奠定了软件工程和工程管理的根底，所以所有风险承当者最好是采用 本书提供的有效的需求分析过程。 本章将帮助你： 了解软件需求开发中使用的一些关键名词。 警惕在软件工程中可能出现的与需求相关的一些问题。 知道优秀的需求规格说明应该具有的特点。 明白需求开发与需求管理之间的区别。 1.1 软件需求的定义 软件产业存在的一个问题就是缺乏统一定义的名词术语来描述我们的工作。客户所定义 的“需求对开发者似乎是一个较高层次的产品概念。而开发人员所说的“需求对用户来 说又像是详细设计了。实际上，软

7、件需求包含着多个层次，不同层次的需求从不同角度与不 同程度反映着细节问题。 IEEE 软件工程标准词汇表 1997年中定义需求为： 1用户解决问题或到达目标所需的条件或权能 Capability。 2系统或系统部件要满足合同、标准、标准或其它正式规定文档所需具有的 条件或权能。 3一种反映上面 1或 2所描述的条件或权能的文档说明。 1.1.1 一些关于“需求的解释 IEEE公布的定义包括从用户角度系统的外部行为，以及从开发者角度一些内部特性 来阐述需求。 关键的问题是一定要编写需求文档。我曾经目睹过一个工程中途更换了所有的开发者， 客户被迫与新的需求分析者坐到一起。分析人员说：“我们想与你谈

8、谈你的需求。客户的第 一反响便是：“我已经将我的要求都告诉你们前任了，现在我要的就是给我编一个系统。而 实际上，需求并未编写成文档，因此新的分析人员不得不从头做起。所以如果只有一堆邮件、 贴条、会谈过几次或一些零碎的对话，你就确信你已明白用户的需求，那完全是自欺欺人。 另外一种定义认为需求是“用户所需要的并能触发一个程序或系统开发工作的说明Jones 1994 。需求分析专家 Alan Davis 1993拓展了这个概念：“从系统外部能发现系统 下载 第1章 根本的软件需求 3所具有的满足于用户的特点、功能及属性等。这些定义强调的是产品是什么样的，而并非产品是怎样设计、构造的。而下面的定义那么

9、从用户需要进一步转移到了系统特性 S o m m e r v i l l eand Sawyer 1997 ： 需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性， 是在开发过程中对系统的约束。 从上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的“需求术语存在，真正的“需求实际上在人们的脑海中。任何文档形式的需求例如：需求规格说明仅是一个模型，一种表达 Lawrence 1998 。我们需要确保所有工程风险承当者在描述需求的那些名词的理解上务必达成共识。1.1.2 需求的层次 下面这些定义是需求工程领域中常见术语的定义说明。 软件需求包括三个不同的层次 业务需求、用户

10、需求和功能需求 也包括非功能需求。业务需求 business requirement 反映了组织机构或客户对系统、产品高层次的目暌螅窃谙钅渴油加敕段牡抵杏枰运得鳌没需求 user requirement 文档描述了用户使用产品必须要完成的任务，这在使用实例 use case 文档或方案脚本 s c e n a r i o说明中予以说明。功能需求 functional requirement 定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。所谓特性 feature是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求各组成局部之间的关系如图 1

11、-1 所示。 业务需求 工程视图与范围文档 用户需求 质量属性 其它非功 使用实例文档 能需求 系统需求 功能需求 约束条件 软件需求规格说明 图1-1 软件需求各组成局部之间的关系 在软件需求规格说明 software requirements specification ，SRS中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开发、测试、质量保证、工程管 4 第一局部 软件需求：是什么和为什么 下载理以及相关工程功能中都起了重要的作用。对一个复杂产品来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于软件部件。 作为功能需求的补充，软件需求规格说明还应

12、包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。 它包括产品必须遵从的标准、标准和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上的限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。 下面以一个字处理程序为例来说明需求的不同种类。业务需求可能是：“用户能有效地纠 ，正文档中的拼写错误 该产品的包装盒封面上可能会标明这是个满足业务需求的拼写检查器。而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词。同时，该拼写检查器还有许

13、多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档范围的替换。 管理人员或市场分析人员会确定软件的业务需求，这使公司运作更加高效对信息系统而言或具有很强的市场竞争力对商业软件产品而言。所有的用户需求必须与业务需求一致。用户需求使需求分析者能从中总结出功能需求以满足用户对产品的要求从而完成其任务，而开发人员那么根据功能需求来设计软件以实现必须的功能。 从以上定义可以发现，需求并未包括设计细节、实现细节、工程方案信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。工程也有其它方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求。尽管这些需求对

14、工程成功也至关重要，但它们并非本书所要讨论的。1.2 每个工程都有需求 Frederick Brooks 在他 1987年的经典的文章“ No Silver Bullet ：Essence and Accidents ofSoftware Engineering 中充分说明了需求过程在软件工程中扮演的重要角色： 开发软件系统最为困难的局部就是准确说明开发什么。最为困难的概念性工作便 是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同 时这也是一旦做错，将最终会给系统带来极大损害的局部，并且以后再对它进行修改 也极为困难。 每个软件产品都是为了使其用户能以某种方式改善他们

15、的生活，于是，花在了解他们需要上的时间便是使工程成功的一种高层次的投资。这对于商业最终用户应用程序，企业信息系统和软件作为一个大系统的一局部的产品是显而易见的。但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道工程于何时结束？而如果我们不知道什么对客户来说是重要的，那我们又如何能使客户感到满意呢？ 然而，即便并非出于商业目的的软件需求也是必须的。例如软件库、组件和工具这些供开发小组内部使用的软件。当然你可能偶尔勿需文档说明就能与其他人意见较为一致，但更常见的是出现重复返工这种不可防止的后果，而重新编制代码的代价远远超过重写一份需求文档的代价。 近来，我遇到一个开发小组开发包

16、括流程图工具和源代码编辑器在内的一套计算机辅助软件工程工具。不幸的是，在他们开发完这个工具后，发现这个工具不能打印出源代码文件，而 下载 第1章 根本的软件需求 5用户当然希望有这个功能。结果这个小组只好手工抄写源代码文档以供代码检查。这说明那怕需求明确无误并构思准确，如果我们没有编写文档，软件达不到期望目标也只能是咎由自取了。 相反的情况，我曾为一个要集成到“商业错误跟踪系统中的简单电子邮件界面写了一页需求说明。而 U n i x 系统管理员在为处理电子邮件写脚本时发现简单的一张需求清单竟是如此有用。我依据需求对系统进行测试时，此系统不仅非常清晰地实现了所有必需功能，而且未发现任何错误。1.

17、3 什么情况将会导致好的群体发生不合格的需求说明 不重视需求过程的工程队伍将自食其果。需求工程中的缺陷将给工程成功带来极大风险，这里的“成功是指推出的产品能以合理的价格、及时限在功能、质量上完全满足用户的期望。下面将讨论一些需求风险。第 5章将介绍怎样应用软件风险管理防止与需求有关的风险的出现。不适当的需求过程所引起的一些风险 用户不多导致产品无法被接受。 用户需求的增加带来过度的消耗和降低产品的质量。 模棱两可的需求说明可能导致时间的浪费和返工。 用户增加一些不必要的特性和开发人员画蛇添足 gold-plating。 过分简略的需求说明以致遗漏某些关键需求。 忽略某类用户的需求将导致众多客户

18、的不满。 不完善的需求说明使得工程方案和跟踪无法准确进行。 1. 无足够用户参与 客户经常不明白为什么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户的参与。究其原因：一是因为与用户合作不如编写代码有意思；二是因为开发人员觉得已经明白用户的需求了。在某些情况下，与实际使用产品的用户直接接触很困难，而客户也不太明白自己的真正需求。但还是应让具有代表性的用户在工程早期直接参与到开发队伍中，并一同经历整个开发过程。 2. 用户需求的不断增加 在开发中假设不断地补充需求，工程就越变越庞大以致超过其方案及预算范围。方案并不总是与工程需求规模与复杂性、风险、开发生产率及需求变更实际情况相一

19、致，这使得问题更难解决。实际上，问题根源在于用户需求的改变和开发者对新需求所作的修改。 要想把需求变更范围控制到最小，必须一开始就对工程视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。说明中包括了对每种变更进行变更影响因素分析的变更控制过程，有助于所有风险承当者明白业务决策的合理性，即为何进行某些变更，相应消耗的时间、资源或特性上的折中。 产品开发中不断延续的变更会使其整体结构日渐紊乱，补丁代码也使得整个程序难以理解和维护。插入补丁代码使模块违背强内聚、松耦合的设计原那么，特别是如果工程配置管理工作不完善的话，收回变更和删除特性会带来问题。如果你

20、尽早地区别这些可能带来变更的特性，你就能开发一个更为健壮的结构，并能更好地适应它。这样设计阶段需求变更不会直接导致补丁代码，同时也有利于减少因变更导致质量的下降。 6 第一局部 软件需求：是什么和为什么 下载 3. 模棱两可的需求 模棱两可是需求规格说明中最为可怕的问题 Lawrence 1996 。它的一层含义是指诸多读者对需求说明产生了不同的理解；另一层含义是指单个读者能用不止一个方式来解释某个需求说明。 模棱两可的需求会使不同的风险承当者产生不同的期望，它会使开发人员为错误问题而浪费时间，并且使测试者与开发者所期望的不一致。一位系统测试人员曾告诉我，她所在的测试组经常对需求理解有误，以致

21、不得不重写许多测试用例并重做许多测试。 模棱两可的需求带来不可防止的后果便是返工 重做一些你认为已做好的事情。返工会消耗开发总费用的 4 0 ，而 7 0 8 5 的重做是由于需求方面的错误所导致的 l e ff i n g w e l l1997。想像一下如果你能减少一半的返工会是怎样的情况？你能更快地开发出产品，在同样的时间内开发更多、更好的产品，甚至能偶尔回家休息休息。 处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍。仅仅简单浏览一下需求文档是不能解决模棱两可问题的。如果不同的评审者从不同的角度对需求说明给予解释，但每个评审人员都真正了解需求文档，这样二义性就不会直到工程

22、后期才被发现，那时再发现的话会使得更正代价很大。其它检测模棱两可需求的技术由 Gause 和 We i n b e rg1989给予介绍，本章的后面也有所涉及。 4. 不必要的特性 “画蛇添足是指开发人员力图增加一些“用户欣赏但需求规格说明中并未涉及的新功能。经常发生的情况是用户并不认为这些功能性很有用，以致在其上消耗的努力“白搭了。开发人员应当为客户构思方案并为他们提供一些具有创新意识的思路，具体提供哪些功能要在客户所需与开发人员在允许时限内的技术可行性之间求得平衡，开发人员应努力使功能简单易用，而不要未经客户同意，擅自脱离客户要求，自作主张。 同样，客户有时也可能要求一些看上去很“酷，但缺

23、乏实用价值的功能，而实现这些功能只能徒耗时间和本钱。为了将“画蛇添足的危害尽量减小，应确信：你明白为什么要包括这些功能，以及这些功能的“来龙去脉，这样使得需求分析过程始终是注重那些能使用户完成他们业务任务的核心功能。 5. 过于精简的规格说明 有时，客户并不明白需求分析有如此重要，于是只作一份简略之至的规格说明，仅涉及了产品概念上的内容，然后让开发人员在工程进展中去完善，结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明。这种方法可能适合于尖端研究性的产品或需求本砭褪至榛畹那榭觯?McConnell 1996 。但在大多数情况下，这会给开发人员带来挫折使他们在不正确的假设前提和极其有

24、限的指导下工作，也会给客户带来烦恼他们无法得到他们所设想的产品 。 6. 忽略了用户分类 大多数产品是由不同的人使用其不同的特性，使用频繁程度也有所差异，使用者受教育程度和经验水平也不尽相同。如果你不能在工程早期就针对所有这些主要用户进行分类的话，必然导致有的用户对产品感到失望。例如，菜单驱动操作对高级用户太低效了，但含义不清的命令和快捷键又会使不熟练的用户感到困难。 7. 不准确的方案 下载 第1章 根本的软件需求 7 “上述是我对新产品的看法，好，现在你能告诉我你什么时候能完成吗？许多开发人员 都遇到这种难题。对需求分析缺乏理解会导致过分乐观的估计，而当不可防止的超支发生时， 会带来颇多麻

25、烦。据报道，导致需求过程中软件本钱估计极不准确的原因主要有以下五点： 频繁的需求变更、遗漏的需求、与用户交流不够、质量低下的需求规格说明和不完善的需求 分析 Davis 1995 。 对不准确的要求所提问题的正确响应是“等我真正明白你的需求时，我就会来告诉你。 基于不充分信息和未经深思的对需求不成熟的估计很容易为一些因素左右。要作出估计时，最好还是给出一个范围如最好的情况下，很可能的，最坏情况下或一个可信赖的程度我有 9 0 的把握，我能在 8 周内完成。未经准备的估计通常是作为一种猜想给出的，听者却 认为是一种承诺。因此我们要尽力给出可到达的目标并坚持完成它。 1.4 高质量的需求过程带来的

26、好处 实行有效的需求工程管理的组织能获得多方面的好处。最大的好处是在开发后期和整个 维护阶段的重做的工作大大减少了。 B o e h m 1 9 8 1 发现要改正在产品付诸应用后所发现的 一个需求方面的缺陷比在需求阶段改正这个错误要多付出 6 8 倍的本钱。近来很多研究说明这 种错误导致本钱放大因子可以高达 2 0 0倍。强调需求质量并不能引起某些人的重视，他们错误 地认为在需求上消耗多少时间就会导致产品开发推迟多少时间。传统的质量本钱角度分析揭 示了需求及其它早期质量工作的重要性 Wiegers 1996a 。 正确的需求过程强调产品开发中的通力合作，包括在整个工程过程中多方风险承当者的 积极努力。收集需求能使开发小组更好地了解市场，而市场因素是任何工程成功的一个关键 因素。在产品开发前了解这些比在遭到客户批评后才意识到要节约很多本钱。让用户积极参 与需求收集过程能使产品更富有吸引力，而且能拥有忠实的客户关系。通过了解用户的任务 需求而不仅仅局限于一些“华美的特性，你能防止在.