《c教程第1章》由会员分享，可在线阅读，更多相关《c教程第1章（14页珍藏版）》请在金锄头文库上搜索。
1、前 言尽管拥有五十年积累的经验，但许多软件开发组织仍不得不在收集、编写和管理产品需求中疲于奔命。而缺乏用户参与、不完整的需求及不断变更需求，是导致信息技术项目不能按进度安排和资金预算完成全部功能的主要原因(The CHAOS Report,The Standish Group International.Inc.,1995)。许多软件开发人员不能熟练地收集客户（customer）需求，很多开发者并不知道实用的需求工程技术，而且教学课程中也是技术主题比需求主题占有优势，工程参与者甚至连“需求”是什么也有不同的看法。软件开发中，信息沟通（交流）至少应与计算占有同等的比重，然而我们往往强调了计算而忽
2、略了信息沟通。本书提供的许多工具将有助于信息交流，同时将帮助软件专业人员、管理者、市场营销者以及客户能应用有效的需求工程方法。本书还介绍了许多方法，用来帮助开发小组和客户一致理解怎样构造一个软件才能满足用户（user）实际的需要，同时也包括了编写文档和管理变更的方法。本书中介绍的技术都代表着需求工程中主流的“良好的习惯做法”，而并非来源于专业领域的高新技术或试图解决所有需求问题的复杂的方法学。本书有益于读者之处本书对你着手的所有软件过程改进，对改善需求开发和管理实践都能提供很多的益处。本书是介绍概念和方法的，并不涉及专门的研究方法学或应用领域，所以它适用于各种项目。我尽力以清晰的结构风格介绍大
3、量实用的且经过验证的技术，希望在以下几个方面能给你提供帮助：u 达到实现更高的客户满意度。u 减少维护和支持费用。u 在开发周期早期提高项目需求分析的质量，减少重复劳动，从而提高生产率。u 通过控制项目范围的扩展(creep)及需求变更，来达到按计划完成预定目标。我的目标是帮助你改进收集和分析需求、编写和修改需求规格说明以及在整个产品开发周期中管理需求。改进过程的最终目的是使你组织中的人员以新的方式进行工作，从而获得更好的结果。因此，希望你能将所学用于实践，而不仅是“纸上谈兵”。实例研究为帮助读者理解怎样应用本书介绍的各种方法，书中提供了几个基于实际项目的实例，其中一个中等规模的信息系统“化学
4、制品跟踪系统”说明了许多实用技术（不必担忧你勿需知道任何关于化学的知识也能理解该项目）。这个实例的项目说明还会帮助你了解怎样把不同的策略（方法）较好地融合到一块。本书中还穿插着源于该实例的项目参与者之间的对话实例。不论你的小组是开发什么软件的，这些对话总是常见的，也是类似的。谁应该读这本书凡参与一个新的或升级的软件产品的需求定义或说明中的任何人员都能从本书中获得有用的信息。这些人中包括那些必须理解并满足用户期望的分析、开发、测试人员；也包括用户，这些用户想定义一种符合他们功能和使用需要的产品。希望确认产品是否满足业务需要的客户将能更好地理解需求分析过程的重要性。而负责监督按期完成产品的项目管理
5、者也将学会怎样管理潜在的威胁需求变更。在许多训练性讨论会中，我发现那些非技术方面的项目参与者也很容易理解本书所涉及的内容。想提高自己对开发过程的理解和想了解需求在软件成功中扮演的关键角色的任何人都将从本书中受益。本书结构本书分为三大部分。第一部分先介绍了一些基本的需求工程定义和一些优秀的需求分析所具有的特性。我希望你与你的重要客户能一起阅读第2章（关于客户与开发者之间的伙伴关系）；第3章介绍了许多需求开发和管理的改进熟练程度的好方法（良好的习惯做法）。第4章有助于计划怎样将新的策略融入小组的开发过程中。方法是基于对附录中当前需求实践自我测试的回答。第5章则介绍了一些通常与需求相关的项目风险。第
6、二部分介绍了许多关于需求开发的技术。首先是定义项目的业务需求，项目视图(wision)及涉及的范围(scope)。接下来的章节介绍怎样为项目寻找合适的客户代表，获取（elicit）用户需求，编写功能需求文档及质量属性文档。第10章介绍了一些分析模型，这些模型可用于不同范围的需求分析。第12章介绍了软件原型的结构和应用。第二部分中的其它章节还探讨了定义需求优先级的方法及验证需求分析是否正确的方法。第三部分的主题是需求管理的原则和策略。这部分还特别介绍了处理需求变更和评价每项变更对项目影响的技术。第18章介绍了怎样把需求跟踪能力和单个需求相关的内容需求来源到与需求相关的设计、代码等）联系起来。第三
7、部分的内容包括一些商业工具的说明，这些工具能增强你管理项目需求的能力。从原理到实践要克服障碍，更改旧的传统做法，把新的知识付诸实践的确不是一件容易的事情。你也许仍想保持原有熟悉（可能并不很有效）的方法，为了帮助你改进需求分析，本书的每一章都包括一个称作“下一步”的内容，它细致地教你如何将本章所学的知识真正开始应用于实践。我提供了许多带有详细注释的模板，包括：需求分析文档、审查校对清单列表、需求优先级电子表格等，所有这些都放在我的网站：http：/上，希望能帮助你尽快把这些技术应用于实践。请从今天就开始，一点一点地逐渐改进你的需求分析。一些项目参与者在尝试新需求技术时是很勉强的。因为有一些人完全
8、不讲理，而与这些不理解的人合作，所有新技术都是没用的。因此将本书介绍的知识告诉你的同事、客户和管理者，用你们以前项目中遇到的与需求有关的问题或困难来提醒他们，与他们一起讨论这些新技术拥有的潜在优势，共同学习、共同提高。你不一定非要在一个新项目中开始应用这种改进的需求工程方法。其实就地改变控制过程就是很好的开端。也就是说，你可以从管理需求变更的请求开始，采用这种比过去更好的方法。因为你能开始作系统的影响分析，创建跟踪能力矩阵，从而把新的需求与相应的设计、代码、测试用例都联系起来了。为现存系统回头重新编写整个系统的需求规格说明是不现实的。但你可以写一个更加结构化的新版本，作一些新特点的分析模型，并
9、调查新的需求。逐渐实施改进的需求，其风险较低，并且也可以为你将新技术应用于下一个主要项目奠定基础。需求工程的目标是做出高质量而并非完美的需求分析，这使得你能在一个可接受的风险限度上实施。为了把返工重做、不被接收的产品及超期未完成这些风险降低到最小程度，你必须花大量的时间来研究需求工程。而本书将有助于确定何时能达到合适的需求分析质量标准，同时还介绍了具体实施方法。致谢我深深地感谢那些花费时间、精力审阅我的手稿并提供了许多改进建议的人们。特别要感谢凯茜弗德，他细致的检查，为我的思考和介绍提供了许多珍贵而深入的想法。我真诚地感谢克瑞丝凡巴斯，汤米汉格森，蒂彭莫勒，麦克瑞巴克，菲尔瑞克其，约翰罗丝曼，
10、路易丝斯塔茨，多瑞丝斯芬伯格，布兰卡哈帕雅，苏格特瑞特曼，他们为每一章节所作的极耗时间的评注。我也很感激那些为某些章节做出努力的人：斯蒂夫安道夫，迪克巴尔科，比尔坦格，德尔爱莫瑞，基尔夫弗兰默克，琳达弗勒明，凯丝格茨，吉姆哈特，迈克梅尔克，他们找出了草稿中的许多错误，而所余下的任何错误都完全是我的疏漏所至。我还要感谢斯蒂夫迈克奈尔，正是他鼓励我写一本软件需求书。还有我的熟人微软出版社的编辑本瑞思，他帮我拓展了研究途径并与外界建立了良好的工作关系。玛丽凯本蒂巴纳德在米切尔古德曼的协助下管理整个过程，并将初稿精心编辑，最终定稿。美术家罗伯耐斯把许多先前的草图绘制成清晰的表格和图形，排版员波纳格里克
11、把它插入到书中。我非常感激我的客户顾问，特别是斯迪布洛林，迈特德沙斯，凯丝弗德，凯丝沃勒斯，他们邀请我参与到他们的需求分析过程中，这对我来说既是指导，又是学习。我特别要感激凯丝弗德愿意将她的经验在本书中予以讨论。还要感谢罗宾古德斯密斯提供的业务需求分析想法以及迈特德沙斯提供的一些典型软件开发工程的极好的术语， 例如：“快速缩小范围阶段”（rapid descoping phase）。本书中介绍的一些技术将它改称为：“受控的缩小范围阶段”（controlled descoping phase）。在过去几年中，参与我需求分析讨论会的上百参与者给与的反馈和贡献是相当有益的，作为一个学者和顾问，我从我
12、工作过的每一个公司中都学到了很多有用的东西，并从讨论参与者的经验交流中也收获颇丰。那些把这些技术应用并发崛其价值的人们所给与的评价，使我更确信：这是项目需求分析所需的实用方法。如果你认为这能有助于工作或不能，请你告诉我：kwiegersacm.org。最后，我将最深的谢意献给我那最富耐心，给予我莫大支持并使我生活充满快乐的妻子克瑞丝扎彼得。有这样一位妻子是任何作者梦寐以求的。 第一部分 软件需求：是什么和为什么第1章 基本的软件需求“喂，是Phil吗？我是人力资源部的Maria，我们在使用你编写的职员系统时遇到一个问题，就是一个职员想把她的名字改成Sparkle Starlight，而系统不允
13、许，你能帮帮忙吗？”“她嫁给了一个姓Starlight 的人吗？”Phil问道。“不，她没有结婚，而仅仅是要更改她的名字，”Maria回答道。“就是这问题，好像我们只能在婚姻状况改变时才能更改姓名。”“当然是这样，我从没想过谁会莫名其妙地更改自己的姓名。我记不起你曾告诉我系统需要处理这样的事情，这就是为什么你们只能在改变婚姻状况对话框中才能进入更改姓名的对话框。”Phil 说道。Maria说：“我想你当然知道每个人只要愿意都可以随时合法更改他（她）们的姓名。但不管怎样，我们希望在下周五之前解决这个不合理的地方，否则，Sparkle将不能支付她的账单。你能在此前修改好这个错误吗？“这并非是个错误
14、！我从来不知道你需要处理这种情况。我现在正忙着做一个新的性能检测系统，并且我还要处理职员系统的一些需求变更请求”（传来翻阅稿纸的声音）。“哦，这儿还有别的事。我只可能在月底前修改好，一周内不行，很抱歉。下次若有类似情况，请早一些告诉我并把它们写下来。”“那我怎么跟Sparkle说呢？”Maria追问道，“如果她不能支付账单，那她只能挂帐了。”“Maria，你要明白，这不是我的过错。”Phil坚持道，“如果你一开始就告诉我，你要能随时改变某个人的名字，那这些都不会发生。因此你不能因未猜出你的想法（需求）就责备我。”Maria不得不很愤怒地屈从道：“好吧，好吧，这种烦人的事使我恨死计算机系统了。等
15、你修改好了，马上打电话告诉我，行吧？”如果你曾作为客户有过类似的对话，你一定知道：一个不能让你进行一项基本操作的软件产品是多么令人烦恼。你不会感谢开发者，尽管他最终会满足你主要的需求变更。但从开发者角度，你也知道，当用户在整个系统已经完成后，再提出一些功能要求是多么烦人的事。同时，由于修改系统的请求会打断你当前的项目，也是令人很不愉快的。而且往往这种修改请求还要求你优先处理。其实，在软件开发中遇到的许多问题，都是由于收集、编写、协商、修改产品需求过程中的手续和作法（方法）失误所带来的。例如上面的Phil和Maria，出现的问题涉及到非正式信息的收集，未确定的或不明确的功能，未发现或未经交流的假
16、设，不完善的需求文档，以及突发的需求变更过程。对大多数人来说，若要建一幢20万美元的房子，他一定会与建房者详细讨论各种细节，他们都明白以后的修改会带来损失，以及变更细节的危害性。然而，到软件开发，人们却变得“大大咧咧”起来。软件项目中百分之四十至百分之六十的问题都是在需求分析阶段埋下的“祸根”（Leffingwell 1997）。可许多组织仍在那些基本的项目功能上采用一些不合规范的方法，这样导致的后果便是一条鸿沟（期望差异）开发者所想开发的与用户所想得到的存在着巨大期望差异。在软件工程中，所有的风险承担者（stakeholder）都感兴趣的就是需求分析阶段。这些风险承担者包括客户、用户、业务或需求分析员（负责收集客户需求并编写文档，以及
