01软件需求基础知识new.docVIP

《软件需求（第2版）》，清华大学出版社，2004-11-1 【原书名】 Software Requirements,Second Edition [原书信息] 【原出版社】 Microsoft Press 【作者】 （美）Karl E.Wiegers 【译者】 刘伟琴 刘洪涛 【开本】 185×260 【页码】 357 1 软件需求基础知识 1 1.1 软件需求的定义 3 1.1.1 对需求的不同解释 4 1.1.2 需求的层次 4 1.1.3 不属于需求的内容 6 1.2 需求的开发与管理 6 1.2.1 需求开发 7 1.2.2 需求管理 7 1.3 所有项目都有需求 8 1.4 优秀的团队遇到糟糕的需求 9 1.4.1 用户参与不足 9 1.4.2 用户需求扩展 10 1.4.3 有歧义的需求 10 1.4.4 镀金问题 10 1.4.5 过于抽象的需求 11 1.4.6 忽略了某类用户 11 1.4.7 不准确的计划 11 1.5 优质需求过程的好处 11 1.6 优秀需求的特点 12 1.6.1 需求陈述的特点 12 1.6.2 需求规格说明的特点 13 软件需求基础知识 “您好。是Phil么？我是人力资源部的Maria。我们使用您做的人事管理系统时遇到点问题。有位女职员想把名字改成Sparklc Starlight，可我们在系统里怎么都改不过来。能帮帮忙吗？” “她嫁了一个姓starlight的人么？” “没有，她没结婚，只是改了名字。”Maria答道，“所以才有这样的麻烦。好像只有在婚姻状况改变时才能改名字。” “是的。我从来没想过谁会无缘无故地改名字。我们讨论系统的时候您可没跟我提过这种可能。所以只能从修改婚姻状况的对话框进入修改名字的对话框。” “谁都可以改名字。只要他愿意，随时都行，这是合法的。我以为您知道呢。”Maria说，“星期五之前必须搞定，不然Sparklc就兑换不了支票。您能在那之前把这个错误改过来么？” “这根本就不是错误！”Phil反驳道，“我从来不知道您需要这个功能。我正忙看做一个新的性能评估系统。而且我还要对人事管理系统进行一些修改，”（话筒里传来翻纸的声音），“对，这就有一个。月底没准能改好，这周肯定不行，抱歉。下回早点儿告诉我，麻烦把问题写下来。” “我怎么跟Sparkle说？”Maria问，“光不了支票她就得赊账。” “搞清楚，Maria，速可不是我的错。”Phil抗议了，“如果您当时告诉我要能随时修改姓名，就不会有今天的事。您不能怪我没猜到您的想法。” Maria很生气却无可奈何，只好气冲冲地说：“好了。就是这种事让我恨透了计算机。改好了马上通知我，这总可以吧。” 如果您曾经有过这种客户经历，您肯定明白这种连最基本的操作都完不成的软件多么让人烦恼。即便开发人员最终可能会帮您改好，您通常也不愿总求助于他。然而，站在开发人员的立场，如果系统完成后才从用户那里得知需要什么功能，也的确很难接受。已经完全按最初的要求实现了系统，却不得不停下手头的项目去修改系统以便满足用户的新需求，这也是件很讨厌的事。 许多软件问题都源于收集、记录、协商和修改产品需求过程中的方式不当。前面Phil和Maria的例子中就有这些方面的问题，包括信息收集方式不正规，没有明确提出想要的功能，假设是未经沟通的错误假设，需求的定义不够充分，以及未经仔细考虑进行需求变更等。 很少有人会甩给建筑商30万美金而不详细说明自己对房子的想法和要求。相反，他们会不厌其烦地提出各种细节要求。要对房子进行改造就得掏钱，购房者尽管不情愿，却都能理解。然而，在软件开发中遇到同样问题时，人们却常常轻率地将其忽略。软件项目中40%～60%的缺陷都是由需求分析阶段的过失所致（Davls 1993；Lc｛Rngwcll｜997）。对欧洲软件行业所做的大规模调查显示：确定和管理用户需求是问题最多的两个环节（ESPITI 1995）。尽管如此，许多组织仍然没有采取有效手段来实施这两个必要的项目活动。由此导致的结果常常是用户和开发者之间产生需求的鸿沟——二者对产品需求的理解相去甚远。 软件或系统项目涉众（stake ho1dcr，产品或项目相关人员）的利益之间的相互作用在需求过程中表现得最为强烈。项目涉众包括： 客户：为达到其公司的业务目标而投资项目或购买产品。 用户：直接或间接与产品打交道，是客户的一部分。 需求分析员：负责编写需求并传达给开发团队。 开发人员：设计、实现和维护产品。 测试人员：确定产品的行为是否与预计的相一致。 文档编制人员：负责编写用户手册、培训资料和系统帮助。 项目经理：制定项目计划并带领开发人员获得成功。 法律人员：确保产品符合所有相关法规。 生产人员：制造包含该软件的产品。 市场营销、技术支