《软件需求分析教程.doc》由会员分享，可在线阅读，更多相关《软件需求分析教程.doc（49页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、目 录前 言-2本书有益于读者之处-2谁应该读这本书-3本书说明-3致谢-4第一部分 软件需求：是什么和为什么-5第一章 基本的软件需求-5软件需求的定义-6需求的层次-7每个项目都有需求-8什么情况导致发生不合格的需求说明-9高质量的需求过程带来的好处-11优秀需求具有的特性-12需求的开发和管理-13第二章 客户的需求观-15谁是客户-15客户与开发人员之间的合作关系-16软件客户需求权利书-17软件客户需求义务书-18 第3章 需求工程的推荐方法-22第4章 改进需求过程-30第5章 软件需求与风险管理-41软件风险管理基础-42编写项目风险文档-44前 言尽管拥有五十年积累的经验，但许
2、多软件开发组织仍不得不在收集、编写和管理产品需求中疲于奔命。而缺乏用户参与、不完整的需求及不断变更需求，是导致信息技术项目不能按进度安排和资金预算完成全部功能的主要原因(The CHAOS Report,The Standish Group International.Inc.,1995)。许多软件开发人员不能熟练地收集客户（customer）需求，很多开发者并不知道实用的需求工程技术，而且教学课程中也是技术主题比需求主题占有优势，工程参与者甚至连“需求”是什么也有不同的看法。软件开发中，信息沟通（交流）至少应与计算占有同等的比重，然而我们往往强调了计算而忽略了信息沟通。本书提供的许多工具将有
3、助于信息交流，同时将帮助软件专业人员、管理者、市场营销者以及客户能应用有效的需求工程方法。本书还介绍了许多方法，用来帮助开发小组和客户一致理解怎样构造一个软件才能满足用户（user）实际的需要，同时也包括了编写文档和管理变更的方法。本书中介绍的技术都代表着需求工程中主流的“良好的习惯做法”，而并非来源于专业领域的高新技术或试图解决所有需求问题的复杂的方法学。本书有益于读者之处Top本书对你着手的所有软件过程改进，对改善需求开发和管理实践都能提供很多的益处。本书是介绍概念和方法的，并不涉及专门的研究方法学或应用领域，所以它适用于各种项目。我尽力以清晰的结构风格介绍大量实用的且经过验证的技术，希望
4、在以下几个方面能给你提供帮助：u 达到实现更高的客户满意度。u 减少维护和支持费用。u 在开发周期早期提高项目需求分析的质量，减少重复劳动，从而提高生产率。u 通过控制项目范围的扩展(creep)及需求变更，来达到按计划完成预定目标。我的目标是帮助你改进收集和分析需求、编写和修改需求规格说明以及在整个产品开发周期中管理需求。改进过程的最终目的是使你组织中的人员以新的方式进行工作，从而获得更好的结果。因此，希望你能将所学用于实践，而不仅是“纸上谈兵”。实例研究为帮助读者理解怎样应用本书介绍的各种方法，书中提供了几个基于实际项目的实例，其中一个中等规模的信息系统“化学制品跟踪系统”说明了许多实用技
5、术（不必担忧你勿需知道任何关于化学的知识也能理解该项目）。这个实例的项目说明还会帮助你了解怎样把不同的策略（方法）较好地融合到一块。本书中还穿插着源于该实例的项目参与者之间的对话实例。不论你的小组是开发什么软件的，这些对话总是常见的，也是类似的。谁应该读这本书Top凡参与一个新的或升级的软件产品的需求定义或说明中的任何人员都能从本书中获得有用的信息。这些人中包括那些必须理解并满足用户期望的分析、开发、测试人员；也包括用户，这些用户想定义一种符合他们功能和使用需要的产品。希望确认产品是否满足业务需要的客户将能更好地理解需求分析过程的重要性。而负责监督按期完成产品的项目管理者也将学会怎样管理潜在的
6、威胁需求变更。在许多训练性讨论会中，我发现那些非技术方面的项目参与者也很容易理解本书所涉及的内容。想提高自己对开发过程的理解和想了解需求在软件成功中扮演的关键角色的任何人都将从本书中受益。本书结构Top本书分为三大部分。第一部分先介绍了一些基本的需求工程定义和一些优秀的需求分析所具有的特性。我希望你与你的重要客户能一起阅读第2章（关于客户与开发者之间的伙伴关系）；第3章介绍了许多需求开发和管理的改进熟练程度的好方法（良好的习惯做法）。第4章有助于计划怎样将新的策略融入小组的开发过程中。方法是基于对附录中当前需求实践自我测试的回答。第5章则介绍了一些通常与需求相关的项目风险。第二部分介绍了许多关
7、于需求开发的技术。首先是定义项目的业务需求，项目视图(wision)及涉及的范围(scope)。接下来的章节介绍怎样为项目寻找合适的客户代表，获取（elicit）用户需求，编写功能需求文档及质量属性文档。第10章介绍了一些分析模型，这些模型可用于不同范围的需求分析。第12章介绍了软件原型的结构和应用。第二部分中的其它章节还探讨了定义需求优先级的方法及验证需求分析是否正确的方法。第三部分的主题是需求管理的原则和策略。这部分还特别介绍了处理需求变更和评价每项变更对项目影响的技术。第18章介绍了怎样把需求跟踪能力和单个需求相关的内容需求来源到与需求相关的设计、代码等）联系起来。第三部分的内容包括一些
8、商业工具的说明，这些工具能增强你管理项目需求的能力。从原理到实践要克服障碍，更改旧的传统做法，把新的知识付诸实践的确不是一件容易的事情。你也许仍想保持原有熟悉（可能并不很有效）的方法，为了帮助你改进需求分析，本书的每一章都包括一个称作“下一步”的内容，它细致地教你如何将本章所学的知识真正开始应用于实践。我提供了许多带有详细注释的模板，包括：需求分析文档、审查校对清单列表、需求优先级电子表格等，所有这些都放在我的网站：http：/上，希望能帮助你尽快把这些技术应用于实践。请从今天就开始，一点一点地逐渐改进你的需求分析。一些项目参与者在尝试新需求技术时是很勉强的。因为有一些人完全不讲理，而与这些不
9、理解的人合作，所有新技术都是没用的。因此将本书介绍的知识告诉你的同事、客户和管理者，用你们以前项目中遇到的与需求有关的问题或困难来提醒他们，与他们一起讨论这些新技术拥有的潜在优势，共同学习、共同提高。你不一定非要在一个新项目中开始应用这种改进的需求工程方法。其实就地改变控制过程就是很好的开端。也就是说，你可以从管理需求变更的请求开始，采用这种比过去更好的方法。因为你能开始作系统的影响分析，创建跟踪能力矩阵，从而把新的需求与相应的设计、代码、测试用例都联系起来了。为现存系统回头重新编写整个系统的需求规格说明是不现实的。但你可以写一个更加结构化的新版本，作一些新特点的分析模型，并调查新的需求。逐渐
10、实施改进的需求，其风险较低，并且也可以为你将新技术应用于下一个主要项目奠定基础。需求工程的目标是做出高质量而并非完美的需求分析，这使得你能在一个可接受的风险限度上实施。为了把返工重做、不被接收的产品及超期未完成这些风险降低到最小程度，你必须花大量的时间来研究需求工程。而本书将有助于确定何时能达到合适的需求分析质量标准，同时还介绍了具体实施方法。致谢Top我深深地感谢那些花费时间、精力审阅我的手稿并提供了许多改进建议的人们。特别要感谢凯茜弗德，他细致的检查，为我的思考和介绍提供了许多珍贵而深入的想法。我真诚地感谢克瑞丝凡巴斯，汤米汉格森，蒂彭莫勒，麦克瑞巴克，菲尔瑞克其，约翰罗丝曼，路易丝斯塔茨
11、，多瑞丝斯芬伯格，布兰卡哈帕雅，苏格特瑞特曼，他们为每一章节所作的极耗时间的评注。我也很感激那些为某些章节做出努力的人：斯蒂夫安道夫，迪克巴尔科，比尔坦格，德尔爱莫瑞，基尔夫弗兰默克，琳达弗勒明，凯丝格茨，吉姆哈特，迈克梅尔克，他们找出了草稿中的许多错误，而所余下的任何错误都完全是我的疏漏所至。我还要感谢斯蒂夫迈克奈尔，正是他鼓励我写一本软件需求书。还有我的熟人微软出版社的编辑本瑞思，他帮我拓展了研究途径并与外界建立了良好的工作关系。玛丽凯本蒂巴纳德在米切尔古德曼的协助下管理整个过程，并将初稿精心编辑，最终定稿。美术家罗伯耐斯把许多先前的草图绘制成清晰的表格和图形，排版员波纳格里克把它插入到书
12、中。我非常感激我的客户顾问，特别是斯迪布洛林，迈特德沙斯，凯丝弗德，凯丝沃勒斯，他们邀请我参与到他们的需求分析过程中，这对我来说既是指导，又是学习。我特别要感激凯丝弗德愿意将她的经验在本书中予以讨论。还要感谢罗宾古德斯密斯提供的业务需求分析想法以及迈特德沙斯提供的一些典型软件开发工程的极好的术语， 例如：“快速缩小范围阶段”（rapid descoping phase）。本书中介绍的一些技术将它改称为：“受控的缩小范围阶段”（controlled descoping phase）。在过去几年中，参与我需求分析讨论会的上百参与者给与的反馈和贡献是相当有益的，作为一个学者和顾问，我从我工作过的每一
13、个公司中都学到了很多有用的东西，并从讨论参与者的经验交流中也收获颇丰。那些把这些技术应用并发崛其价值的人们所给与的评价，使我更确信：这是项目需求分析所需的实用方法。如果你认为这能有助于工作或不能，请你告诉我：kwiegersacm.org。最后，我将最深的谢意献给我那最富耐心，给予我莫大支持并使我生活充满快乐的妻子克瑞丝扎彼得。有这样一位妻子是任何作者梦寐以求的。 第一部分 软件需求：是什么和为什么第一章 基本的软件需求Top “喂，是Phil吗？我是人力资源部的Maria，我们在使用你编写的职员系统时遇到一个问题，就是一个职员想把她的名字改成Sparkle Starlight，而系统不允许，
14、你能帮帮忙吗？”“她嫁给了一个姓Starlight 的人吗？”Phil问道。“不，她没有结婚，而仅仅是要更改她的名字，”Maria回答道。“就是这问题，好像我们只能在婚姻状况改变时才能更改姓名。”“当然是这样，我从没想过谁会莫名其妙地更改自己的姓名。我记不起你曾告诉我系统需要处理这样的事情，这就是为什么你们只能在改变婚姻状况对话框中才能进入更改姓名的对话框。”Phil 说道。Maria说：“我想你当然知道每个人只要愿意都可以随时合法更改他（她）们的姓名。但不管怎样，我们希望在下周五之前解决这个不合理的地方，否则，Sparkle将不能支付她的账单。你能在此前修改好这个错误吗？“这并非是个错误！我
15、从来不知道你需要处理这种情况。我现在正忙着做一个新的性能检测系统，并且我还要处理职员系统的一些需求变更请求”（传来翻阅稿纸的声音）。“哦，这儿还有别的事。我只可能在月底前修改好，一周内不行，很抱歉。下次若有类似情况，请早一些告诉我并把它们写下来。”“那我怎么跟Sparkle说呢？”Maria追问道，“如果她不能支付账单，那她只能挂帐了。”“Maria，你要明白，这不是我的过错。”Phil坚持道，“如果你一开始就告诉我，你要能随时改变某个人的名字，那这些都不会发生。因此你不能因未猜出你的想法（需求）就责备我。”Maria不得不很愤怒地屈从道：“好吧，好吧，这种烦人的事使我恨死计算机系统了。等你修
16、改好了，马上打电话告诉我，行吧？”如果你曾作为客户有过类似的对话，你一定知道：一个不能让你进行一项基本操作的软件产品是多么令人烦恼。你不会感谢开发者，尽管他最终会满足你主要的需求变更。但从开发者角度，你也知道，当用户在整个系统已经完成后，再提出一些功能要求是多么烦人的事。同时，由于修改系统的请求会打断你当前的项目，也是令人很不愉快的。而且往往这种修改请求还要求你优先处理。其实，在软件开发中遇到的许多问题，都是由于收集、编写、协商、修改产品需求过程中的手续和作法（方法）失误所带来的。例如上面的Phil和Maria，出现的问题涉及到非正式信息的收集，未确定的或不明确的功能，未发现或未经交流的假设，
17、不完善的需求文档，以及突发的需求变更过程。对大多数人来说，若要建一幢20万美元的房子，他一定会与建房者详细讨论各种细节，他们都明白以后的修改会带来损失，以及变更细节的危害性。然而，到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”（Leffingwell 1997）。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟（期望差异）开发者所想开发的与用户所想得到的存在着巨大期望差异。在软件工程中，所有的风险承担者（stakeholder）都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求
18、分析员（负责收集客户需求并编写文档，以及负责客户与开发机构之间联系沟通的人）、开发人员、测试人员、用户文档编写者、项目管理者和客户管理者。这部分工作若处理好了，能开发出很出色的产品，同时会使客户感到满意，开发者也倍感满足、充实。若处理不好，则会导致误解、挫折、障碍以及潜在质量和业务价值上的威胁。因为需求分析奠定了软件工程和项目管理的基础，所以所有风险承担者最好是采用下面提供的有效的需求分析过程。本章将帮助你：u 了解软件需求开发中使用的一些关键名词。u 警惕在软件项目中可能出现的与需求相关的一些问题。u 知道优秀的需求规格说明应该具有的特点。u 明白需求开发与需求管理之间的区别。软件需求的定义
19、Top软件产业存在的一个问题就是缺乏统一定义的名词术语来描述我们的工作。客户所定义的“需求”对开发者似乎是一个较高层次的产品概念。而开发人员所说的“需求”对用户来说又像是详细设计了。实际上，软件需求包含着多个层次，不同层次是从不同角度与不同程度反映着细节问题。IEEE软件工程标准词汇表（1997年）中定义需求为：（1） 用户解决问题或达到目标所需的条件或权能（Capability）。（2） 系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。（3） 一种反映上面（1）或（2）所描述的条件或权能的文档说明。一些关于“需求”的解释IEEE公布的定义包括从用户角度（系统的外部
20、行为），以及从开发者角度（一些内部特性）来阐述需求。一个很关键的问题是一定要编写需求文档。我曾经目睹过一个项目中途更换了几乎所有的开发者，客户被迫又与新的需求分析者坐到一起。分析人员说：“我们想与你谈谈你的需求。”客户的第一反应便是：“我已经将我的要求都告诉你们前任了，就是给我编一个系统”。而实际上，需求并未编写成文档，因此新的分析人员不得不从头做起。所以事实上你只有一堆邮件、贴条、会谈过几次或一些零碎的对话，要是你确信你已明白需求，那完全是在自欺欺人。另外一种定义认为需求是“用户所需要的并能触发一个程序或系统开发工作的说明”（Jones 1994）。需求分析专家Alan Davis （199
21、3）拓展了这个概念：“从系统外部能发现系统所具有的满足于用户的特点、功能、属性等”。这些定义强调的都是产品是什么样的，而并非产品是怎样设计、构造的。而下面的定义则从用户需要进一步转移到了系统特性（Sommerville和 Sawyer 1997）：需求是指明必须实现什么样的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。从上面这些不同形式的定义不难发现：并没有一个清晰、毫无二义性的“需求”术语存在，真正的“需求”实际上在人们的脑海中。任何文档形式的需求（例如：需求规格说明）仅是一个模型，一种叙述（Lawrence 1998）。我们需要确保所有项目风险承担者在描述需求的那些
22、名词的理解上务必达成共识。需求的层次Top下面这些定义是需求工程领域中常见术语的定义说明。软件需求包括三个不同的层次业务需求、用户需求和功能需求也包括非功能需求。业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求(user requirement) 文档描述了用户使用产品必须要完成的任务，这在使用实例（use case）文档或方案脚本（scenario）说明中予以说明。功能需求(functional requirement)定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需
23、求。所谓特性(feature)是指逻辑上相关的功能需求的集合，给用户提供处理能力并满足业务需求。软件需求各组成部分之间的关系如图1-1所示。在软件需求规格说明（software requirements specification简称“SRS”）中说明的功能需求充分描述了软件系统所应具有的外部行为。软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。对一个复杂产品来说，软件功能需求也许只是系统需求的一个子集，因为另外一些可能属于软件部件。作为功能需求的补充，软件需求规格说明还应包括非功能需求，它描述了系统展现给用户的行为和执行的操作等。 它包括产品必须遵从的标准
24、、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。所谓约束是指对开发人员在软件产品设计和构造上所具有的选择限制。质量属性是通过多种角度对产品的特点进行描述，从而反映产品功能，多角度描述产品对用户和开发人员都极为重要。下面以一个字处理程序为例来说明需求的不同种类。业务需求可能是：“用户能有效地纠正文档中的拼写错误”，该产品的包装盒封面上可能会标明这个满足业务需求的拼写检查器。而对应的用户需求可能是“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。同时，该拼写检查器还有许多功能需求，如找到并高亮度提示错词的操作；显示提供替换词的对话框以及实现整个文档
25、范围的替换。管理人员或市场分析人员会确定软件的业务需求，这有利于公司操作更加高效（对信息系统而言）或具有很强的市场竞争力（对商业软件产品而言）。所有的用户需求必须与业务需求一致。用户需求允许需求分析者能从中得到一些功能需求以满足用户使用产品来完成其任务，而开发人员则利用功能需求来设计如何实现必须的功能。从以上定义可以发现，需求并未包括设计细节、实现细节、项目计划信息或测试信息。需求与这些没有关系，它关注的是充分说明你究竟想开发什么。项目也有其它方面的需求，如开发环境需求或发布产品及移植到支撑环境的需求。尽管这些需求对项目成功也至关重要，但它们并非本书所要讨论的。每个项目都有需求TopFrede
26、rick Brooks在他1987年的经典的文章“No Silver Bullet：Essence and Accidents of Software Engineering ”中充分说明了需求过程在软件项目中扮演的重要角色：开发软件系统最为困难的部分就是准确说明开发什么。最为困难的概念性工作便是编写出详细技术需求，这包括所有面向用户、面向机器和其它软件系统的接口。同时这也是一旦做错，将会最终给系统带来极大损害的部分，而且以后再对它进行修改也极为困难。每个软件产品都是为了使其用户能以某种方式改善他们的生活，于是，花在了解他们需要上的时间便是使项目成功的一种高层次的投资。这对于商业最终用户应用程
27、序，企业信息系统和软件作为一个大系统的某一部分的产品是显而易见的。但是对于我们开发人员来说，并没有编写出客户认可的需求文档，我们如何知道项目于何时结束？而如果我们不知道什么对客户来说很重要，那我们又如何能使客户感到满意呢？然而，即便并非出于商业目的的软件需求也是必须的。例如软件库、组件和工具这些供一个开发小组内部使用的软件。当然你可能偶然地勿需文档说明就能与其他人意见接近一致，但更常见的是出现重复返工这种不可避免的后果，而重新编制代码的代价远远超过重写一份需求文档的代价。近来，我遇到一个开发小组开发包括流程图工具和源代码编辑器在内的一套计算机辅助软件工程工具。不幸的是，在他们开发完这个工具后，
28、发现这个工具不能打印出源代码文件，而用户当然希望有这个功能。结果这个小组只好手工抄写源代码文档以供代码检查。这说明如果我们没有编写文档，那怕这种需求是明确无误和设想的，软件达不到期望目标也只是是咎由自取了。相反的情况，我曾为一个要集成到“商业错误跟踪系统”中的简单电子邮件界面写了一页需求说明。而Unix系统管理员在为处理电子邮件写脚本时发现如此简单的一张需求清单竟是如此有用。我依据需求进行测试时，不仅非常清晰地实现了所有必需功能，而且未发现任何错误。什么情况将会导致好的群体发生不合格的需求说明Top不重视需求过程的项目队伍将自食其果。需求工程中的缺陷将给项目成功带来极大风险，这里的“成功”是指
29、推出的产品能以合理的价格、及时地完成并在功能、质量上完全满足用户的期望。下面将讨论一些需求风险。第5章将介绍怎样应用软件风险管理从而防止与需求有关的风险的出现和不适当的需求过程所引起的一些风险。u 包含的用户数不多将导致无法接受的产品。u 用户需求的扩展将带来过度的耗费和降低产品的质量。u 模棱两可的需求说明可能导致时间浪费和返工。u 用户增加一些不必要的特性和开发人员“画蛇添足(gold-plating)”的追求。u 过分精简的需求说明以致遗漏某些关键需求。u 忽略某一部分用户类的需求将导致众多客户的不满。u 不完善的需求说明使得项目计划和跟踪等无法准确进行。无足够用户参与客户经常不明白为什
30、么收集需求和确保需求质量需花费那么多功夫，开发人员可能也不重视用户参与。究其原因：一来因为与用户合作不如编写代码有兴趣；二来因为他们觉得已经明白用户的需求了。在某些情况下，与实际使用产品的用户直接接触很困难，而客户也不太明白用户的真正需求。但还是应让具有代表性的用户在项目早期直接参与到开发队伍中，并一同经历整个开发过程。用户需求的不断扩展在开发中若不断地补充需求，项目就越变越庞大以致超过其计划安排及预算范围。计划并不总是贴近项目需求规模与复杂性的实际情况、风险、开发生产率及需求变更情况，这使得问题更难解决。实际上，问题根源在于用户对需求的改变和开发者对新需求所作的修改。要控制变更范围的不断扩展
31、，必须一开始就对项目视图、范围、目标、约束限制和成功标准给予明确说明，并将此说明作为评价需求变更和新特性的参照框架。说明中包括了对每种变更进行变更影响因素分析的变更控制过程，这也将有助于所有风险承担者明白业务决策的合理性，为何进行某些变更，以及相应消耗的时间、资源或特性上的折中。产品开发中不断延续的变更会使其整体结构日渐紊乱，补丁代码也使得整个程序难以理解和维护。插入补丁代码也使模块违背强内聚、松耦合的设计原则，特别是如果项目配置管理工作也不完善的话，收回变更和删除特性也会带来问题。如果你能尽早区别这些可能带来变更的特性，你就能开发一个更为健壮的结构，并能更好地适应它，这样设计阶段需求变更不会
32、直接导致补丁代码，同时也有利于控制因变更导致质量的下降。模棱两可的需求模棱两可是需求规格说明中最为可怕的问题(Lawrence 1996)。它的一层含义是指诸多读者对需求说明产生了不同的理解；另一层含义是指单个读者能用不止一个方式来解释某个需求说明。模棱两可的需求会使不同的风险承担者产生不同的期望，它会使开发人员为错误问题而浪费时间，并且使测试者与开发者所期望的也不一致。一位系统测试人员曾告诉我，她所在的测试组经常对需求理解有误，以致不得不重写许多测试用例和重做许多测试。模棱两可的需求带来不可避免的后果便是返工重做一些你认为已做好的事情。返工会耗费开发总费用的百分之四十，而百分之七十至八十五的
33、重做是由于需求方面的错误所导致的（leffingwell 1997）。想像一下如果你能减少一半的返工会是怎样的情况？你能更快地开发出产品，在同样的时间内开发更多、更好的产品，或甚至能偶尔回家休息休息。处理模棱两可需求的一种方法是组织好负责从不同角度审查需求的队伍。仅仅简单浏览一下需求文档是不能解决模棱两可问题的。如果不同的评审者从不同的角度对需求说明给予解释，但使得每个评审人员都有所了解，这样二义性就不会直到项目后期才被发现，那时才发现的话会使得更正代价很大。其它检测模棱两可的技术由Gause 和Weinberg（1989）给予了介绍，本章的后面也有所涉及。不必要的特性“画蛇添足”是指开发人员
34、力图增加一些“用户欣赏”但需求规格说明中并未涉及的新功能性。经常发生的情况是用户并不认为这些功能性很有用，以致在其上耗费的努力“白搭”了。开发人员应当为客户构思方案和出于他们考虑的一些创新思路，具体确定哪些功能是要在客户所需与开发人员在允许时限内的技术可行性之间求得平衡，开发人员应努力使其简单易用，而不要未经客户同意，擅自脱离客户要求，自作主张。同样，客户有时也可能要求一些看上去很“酷”，但缺乏实用价值的功能，而这些只能徒耗时间和成本。为了将“画蛇添足”的危害尽量减小，应确信：你明白为什么要包括这些功能，以及关于这些功能的“来龙去脉”，这样使得需求分析过程始终是注重那些能使用户完成他们业务任务
35、的核心功能。过于精简的规格说明有时，客户并不明白需求分析有如此重要，于是只作一份精简之至的规格说明，仅涉及了产品概念上的内容，然后让开发人员在项目进展中去完善，结果很可能出现的是开发人员先建立产品的结构之后再完成需求说明。这种方法可能适合于尖端研究性的产品或需求本身就十分灵活的情况（Mc Connell 1996）。但在大多数情况下，这会给开发人员带来挫折（使他们在不正确的假设前提下和极其有限的指导下工作），也会给客户带来烦恼（他们无法得到他们所设想的产品）。忽略了用户分类大多数产品是由不同的人使用其不同的特性，使用频繁程度也有所差异，使用者受教育程度和经验水平也不尽相同。如果你不能在项目早期
36、就针对所有这些主要用户进行分类的话，必然导致有的用户对产品感到失望。例如，菜单驱动操作对高级用户太低效了，但含义不清的命令和快捷键又会使不熟练的用户感到困难。不准确的计划“上述是我对新产品的看法，好，现在你能告诉我你什么时候能完成吗？”许多开发人员都遇到这种难题。对需求分析缺乏理解会导致过分乐观的估计，而当不可避免的超支发生时，会带来颇多麻烦。据报道，导致需求过程中软件成本估计极不准确的原因主要有以下五点：频繁的需求变更；遗漏的需求；与用户交流不够；质量低下的需求规格说明和不完善的需求分析（Davis 1995）。对估计时间要求提问的正确响应是“等我真正明白你的需求时，我就会来告诉你”。基于不
37、充分信息和未经深思的不成熟估计很容易被一些因素推迟。当要作出估计时，最好还是给出一个范围（如最好的情况下，很可能的，最坏情况下）或一个可信赖的程度（我有90%的把握，我能在8周内完成）。通常未经准备的估计是作为一种猜测而给出的，听者却认为是一种承诺。因此我们要尽力给出可达到预期的期望并坚持一贯如此。高质量的需求过程带来的好处Top实行有效的需求工程管理的组织能获得多方面的好处。也许最大的好处是在开发后期和整个维护阶段的返工重做大大减少了。Boehm（1981）发现要改正在产品付诸应用后所发现的一个需求方面的缺陷比在需求阶段改正这个错误多出68倍的成本。近来很多研究表明这个错误导致成本放大因子可
38、以高达200倍这么高。强调需求质量并不能引起某些人的重视，他们错误地认为在需求上消耗多少时间就会导致产品开发推迟多少时间。从传统的质量成本角度分析来看，揭示了需求及其它早期质量工作的重要性（Wiegers 1996a）。正确的需求过程强调产品开发中的通力合作，包括在整个项目过程中多方面风险承担者的积极努力。由于收集需求能使开发小组更好地了解其市场，而市场因素是任何项目成功的一个关键因素。在产品开发前了解这些比在遭到客户批评后才意识到要节约很多成本。让用户积极参与需求收集过程能使产品更富有吸引力，而且能拥有忠实的客户关系。通过了解用户的任务需求而不是仅仅局限于一些“华丽”的特性，你能避免在无用功
39、能上白耗精力，并且用户的参与能弥补用户期望获得和开发者实际开发之间的“鸿沟（期望差异）”。将选定系统的需求明确地分配到各软件子系统，强调采用产品工程的系统方法。这样能简化硬软件的集成，也能确保软硬件系统功能匹配适当。而有效的变更控制和影响分析过程也能降低需求变更带来的影响。最后，将需求编写成清晰、无二义性的文档将会极大的有利于系统测试，确保产品质量，以使所有风险承担者感到满意。优秀需求具有的特性Top怎样才能把好的需求规格说明和有问题的需求规格说明区别开来？下面讨论单个需求陈述说明的几个特点（Davis 1993；IEEE 1998）。让风险承担者从不同角度对SRS需求说明进行认真评审，能很好
40、地确定哪些需求确实是需要的。只要你在编写、评审需求时把这些特点记在心中，你会写出更好的（尽管并不十分完美）需求文档，同时你也会开发出更好的产品。在第9章中，我们将使用这些特点找到一些需求陈述中的问题并改进之。需要说明的特征完整性每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。正确性每一项需求都必须准确地陈述其要开发出的功能性。判断正确的参考是需求的来源，如客户或高层的系统需求规格说明。若软件需求与对应的系统需求相抵触则是不正确的。只有用户代表才能确定用户需求的正确性，这就是为何一定要有用户的积极参与的原因。没有用户参与的需求评审将导致类似说法：“
41、那些毫无意义，这些才很可能是他们所要想的。”其实这完全是评审者凭空猜测。可行性每一项需求都必需是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求，最好在获取（elicitation）需求(收集需求)过程中始终有一位软件工程小组的组员与需求分析人员或考虑市场的人员在一起工作，由他来负责技术可行性上的检查。必要性每一项需求都应把客户真正所需要的和最终系统所需遵从的标准记录下来。“必要性”也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入，如使用实例或别的来源。划分优先级给每项需求、特性或使用实例分配一个实施优先级以指明它在特定产品中所占的分量
42、。如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度。第13章将更详细地讨论如何划分优先级。无二义性对所有需求说明的读者都只能有一个明确统一的解释，由于自然语言极易导致二义性，所以尽量把每项需求用简洁明了的用户性的语言表达出来。避免二义性的有效方法包括对需求文档的正规审查，编写测试用例，开发原型以及设计特定的方案脚本。可验证性检查一下每项需求是否能通过设计测试用例或其它的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析了。一份前后矛盾，不可行或有二义性的需求也是不可验证的。需求规格说
43、明的特点完整性不能遗漏任何必要的需求信息。遗漏需求将很难查出。注重用户的任务而不是系统的功能将有助于你避免不完整性。如果知道缺少某项信息，用TBD(“待确定”)作为标准标识来标明这项缺漏。在开始开发之前，必须解决需求中所有的TBD项。一致性一致性是指与其它软件需求或高层（系统，业务）需求不相矛盾。在开发前必须解决所有需求间的不一致部分。只有进行一番调查研究，你才能知道某一项需求是否确实正确。可修改性在必要时或为维护每一需求变更历史记录时，应该修订SRS。这就要求每项需求要独立标出，并与别的需求区别开来，从而无二义性。每项需求只应在SRS中出现一次。这样更改时易于保持一致性。另外，使用目录表、索
44、引和相互参照列表方法将使软件需求规格说明更容易修改。可跟踪性应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立起链接链，这种可跟踪性要求每项需求以一种结构化的，粒度好（fine-grained）的方式编写并单独标明，而不是大段大段的叙述。第18章将详细说明需求的可跟踪性。需求的开发和管理Top需求中名词术语的混淆将导致对科目（规范）（discipline）叫法的不一致。一些作者把整个需求范围称之为“需求工程”，而另一些则称之为“需求管理”。我认为可把整个软件需求工程研究领域划分为需求开发（本书的第二部分）和需求管理（本书第三部分）两部分更合适，如图1-2所示： 需求开发可进一步分为：问题获取（elicitation）、分析(analysis)、编写规格说明（specification）和验证（verification）四个阶段（Thayer和Dorfman 1997）。这些子项包括软件类产品中需求收集、评价、编写文档等所有活动。需求开发活动包括以下几个方面：u 确定产品所期望的用户类。u 获取每个用户类的需求。u 了解实际用户任务和目标以及这些任务所支持的业务需求。u