一、什么是质量？ 作为软件产品的销售人员，市场人员或维护人员经常会受到客户这样那样的指责或抱怨，客户说：你们产品的质量太差，不稳定等等。那么什么是质量呢？我们该如何来衡量质量呢？ 质量具有三个维度： ?? 符合目标。目标是客户所定义的，符合目标即判断我们是不是在做需要做的事情。 ?? 符合需求。即产品是不是在做让它做的事情。 ?? 符合实际需求。实际的需求包括用户明确说明的和隐含的需求。 ISO 关于质量的定义表示如下： “ 一个实体（产品或服务）的所有特性，基于这些特性可以满足明显的或隐含的需要。 ” 注意，在这个定义中包含明显的需求和隐含的需求。而往往我们会忽略隐含的需求。因此在控制一个产品的质量的过程中必须关注这些隐含的需求，并给予应有的验证。 另一方面因为我们的产品是为客户提供服务的，因此凡是不满足客户需求的，我们都认为是一个失效（ failure ）。所以我们的产品必须始终围绕着客户的需求进行开发和验证。 这里我们谈到客户，其实在一个软件的需求收集过程中需要关注客户和用户。而我们经常会忽略客户与用户之间的区别。那么谁是客户？谁是用户呢？简单的来说，客户是真正能够决定是否购买你软件的人，而用户是实际使用软件的人。了解了这个区别，对于你在分析需求的重要性的时候就可以进行参考。同时在产品质量验证的时候也可以做出不同的权衡。另一方面我们在考虑我们用户需求的时候，往往只考虑了实际使用软件的人员，而忽略了其它一些人员对软件的要求或对软件造成的潜在竞争，这包括维护人员的要求、系统管理人员的要求、软件上下游人员的要求、先前版本的情况、市场上竞争对手的软件情况等。 每个人提到质量的时候，经常会遇到下列矛盾，在这些矛盾中隐含着对质量的承诺【 5 】： ?? 质量需要一个承诺，尤其是高层管理者的承诺。但为了得到质量，高层管理者必须和其雇用的员工进行紧密合作； ?? 许多人相信没有缺陷的产品和服务是不可能的。但是控制在一定级别的缺陷数是正常并可接受的； ?? 质量经常是和成本紧密联系在一起，一个高质量的产品同时也意味着高投入。这是设计的质量和一致性质量的一个矛盾； ?? 一个高的质量要求需求规格说明书足够详细，以便产品可以根据这些规格说明书进行定量的分析。然而许多组织没有能力或者不愿意产生如此详细程度的规格说明书； ?? 技术人员经常相信规范和标准会束缚他们的创造力，因此就不遵照标准做事。然而如果要得到高质量的产品，就必须遵循良好定义的标准和过程。 二、流程对质量的贡献 好了，既然已经了解了什么是质量，那么怎么才能改进软件产品的质量呢？从一个企业的长远发展来看，首先应当从流程抓起，规范软件产品的开发过程。这是一个软件企业从小作坊的生产方式向集成化、规范化的大公司迈进的必经之路，也是从根本上解决质量问题，提高工作效率的一个关键手段。 软件产品的开发同其它产品（如汽车）的生产有着共同特性，即需要按一定的过程来进行生产。在工业界，流水线生产方式被证明是一种高效且能够比较稳定地保证产品质量的一种方式。通过这种方式，不同的人员被安排在流程的不同位置，最终为着一个目标共同努力，这样可以防止人员工作间的内耗，极大的提高工作效率。并且由于其过程来源于成功的实例，因此其最终的产品质量能够满足过程所设定的范围要求。软件工程在软件的发展过程中吸取了这个经验并把它应用到了软件开发中，这就形成了软件工程过程，简单的说就是开发流程。 无论做什么事情，都有一个循序渐进的过程，从计划到策略再到实现。软件流程就是按照这种思维来定义开发过程，它根据不同的产品特点和以往的成功经验，定义了从需求到最终产品交付的一整套流程。流程告诉我们该怎么一步一步去实现产品，可能会有那些风险，如何去避免风险等等。由于流程来源于成功的经验，因此，按照流程进行开发可以使得我们少走弯路，并有效的提高产品质量，提高用户的满意度。 目前流行的流程方法有很多种，不同的过程模型适合于不同类型的项目。瀑布模型是应用的最为广泛的一种模型，也是最容易理解和掌握的模型，然而它的缺陷也是显而易见的。遗漏的需求或者不断变更的需求会使得该模型无所适从。然而，对于那些容易理解但很复杂的项目，采用瀑布模型会是比较适合的，因为你可以按部就班的去处理复杂的问题。在质量要求高于成本和进度要求的时候，该模型表现的尤其突出。 螺旋模型是也是一个经典模型，它关注于发现和降低项目的风险【 8 】。螺旋型项目从小的规模开始，然后探测风险，制定风险控制计划，接着确定下一步项目是否还要继续，然后进行下一个螺旋的反复。该模型的最大优点就是随着成本的增加，风险程度随之降低。然而螺旋模型的缺点是比较复杂，且需要管理人员有责任心，专注以及有管理方面经验。 RUP （ Rational Unified Process ）是 Rational 公司提出的一套开发过程模型，它是一个面向对象软件工程的通用业务流程【 9 】。它描述了一系列相关的软件工程流程，它们具有相同的结构，即相同的流程构架。 RUP 为在开发组织中分配任务和职责提供了一种规范方法，其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件。 RUP 具有两个轴，一个是时间轴，这是动态的。另一个是工作流轴，这是静态的。在时间轴上， RUP 划分了四个阶段：初始阶段、细化阶段、构造阶段和发布阶段。每个阶段都使用了迭代的概念。在工作流轴上， RUP 设计了六个核心工作流程和三个核心支撑工作流程，核心工作流轴包括：业务建模工作流、需求工作流、分析设计工作流、实现工作流、测试工作流和发布工作流。核心支撑工作流包括：环境工作流、项目管理工作流和配置与变更管理工作流。具体可以参考图 1 。 RUP 汇集现代软件开发中多方面的最佳经验，并为适应各种项目及组织的需要提供了灵活的形式。作为一个商业模型，它具有非常详细的过程指导和模板。但是同样由于该模型比较复杂，因此在模型的掌握上需要花费比较大的成本。尤其对项目管理者提出了比较高的要求。 图1 RUP 工作流程示意图 IPD （ Integrated Product Development ）流程是由 IBM 提出来的一套集成产品开发流程，非常适合于复杂的大型开发项目，尤其涉及到软硬件结合的项目。 IPD 从整个产品角度出发，流程综合考虑了从系统工程、研发（硬件、软件、结构工业设计、测试、资料开发等）、制造、财务到市场、采购、技术支援等所有流程。是一个端到端的流程。在 IPD 流程中总共划分了六个阶段（概念阶段、计划阶段、开发阶段、验证阶段、发布阶段和生命周期阶段），四个个决策评审点（概念阶段决策评审点、计划阶段决策评审点、可获得性决策评审点和生命周期终止决策评审点）以及六个技术评审点，具体可以参考图 2 。 IPD 流程是一个阶段性模型，具有瀑布模型的影子。该模型通过使用全面而又复杂的流程来把一个庞大而又复杂的系统进行分解并降低风险。一定程度上，该模型是通过流程成本来提高整个产品的质量并获得市场的占有。由于该流程没有定义如何进行流程回退的机制，因此对于需求经常变动的项目该流程就显得不大适合了。并且对于一些小的项目，也不是非常适合使用该流程。 图2 IPD 流程示意图 三、流程与技术 流程和成功不是等价的。没有流程就成功是不可能得到保证，但有了流程并不意味着肯定能够成功。这恐怕是很多迷信于流程的人所不能接受的。但这的确是个事实。记得有个做了将近 30 多年的需求分析专家说过：即使是一个已经达到 CMM4 级的公司，也完全有可能做不好需求分析。为什么？技术，技术是成功的另外一个必要条件。就好比现在你要从上海到北京去，流程给你指出了最短的路径，技术提供给你最快的交通工具。两者结合就是完美。 对于软件开发来说，要保证软件的质量，需要掌握多方面的技术，包括分析技术、设计技术、编码技术和测试技术等等。在国内有一个普遍的非正常现象，就是大家觉得只有编程能力才是玩电脑的真正技能。就好像造一套房子，其它都不重要，只要砖瓦匠有高超的技能就行了。尽管这个比喻会打击很多程序员的自尊心，但这的确是一个事实。我们缺少系统级的工程师，在分析和设计方面的工作做得很不扎实。 需求是一个项目的灵魂。模棱两可的需求带来不可避免的后果便是返工 —— 重做一些你认为已做好的事情。返工会耗费开发总费用的 4 0 % ，而 7 0 % ～ 8 5 % 的重做是由于需求方面的错误所导致的（ l e ff i n g w e l l1 9 9 7 ）【 10 】。想像一下如果你能减少一半的返工会是怎样的情况？你能更快地开发出产品，在同样的时间内开发更多、更好的产品，甚至能偶尔回家休息休息。在《软件需求》一书中关于如何进行需求分析给出了比较详细的介绍【 7 】， RUP 中关于需求的指导也是很实用的。 设计是最能体现一个工程师能力和水平的环节。一个好的设计基本上决定了产品的最终质量。设计是把需求转换成系统的一个关键步骤，它需要从自然语言描述的需求中寻找出设计的基础单元，构建出整个系统的构架。在 RUP 中关于系统构架师和设计师的定位是相当高的。关于设计方面的技能涉及面是很广的，包括传统的结构化设计到面向对象设计。设计人员需要掌握一定的建模技术。 UML 是国际上比较流行的一种建模语言【 11 】。在嵌入式方面， SDL 也是一种非常好的选择。《设计模式》是在设计思想方面总结的非常出色的一本书【 6 】，作为一名设计人员（尤其是面向对象设计人员）必须要好好研究一下。但是对这些模式的应用应当讲究一种自然的应用，千万不要因为模式而去设计模式，否则会适得其反。 现在的程序员热中于掌握多种编程语言，或者讲究语言的过分技巧化，而往往忽略了编程语言的规范化。不规范的语言应用给程序的可理解性、可维护性以及可测试性带来了大的伤害，进而损害了产品的质量。某公司曾对中国程序员和印度程序员做过一个测验，这个测验要求参加者对一组数进行排序。测试结果发现，印度程序员设计的程序使用的算法并不是最优，但却是最不容易出错的，并且几个程序员写出来的代码如出一辙。而几个中国程序员写出的代码，有的非常漂亮，很精练，效率很高；有的却很冗杂，还有错误。如果大家是在做研究性的项目或纯粹兴趣性的项目，那么充分发挥自己的编程天才也无可厚非。然而，对于一个软件公司，产品最终是要交给用户的，需要遵循的是一个软件产品的开发工程。因此这类软件的开发需要遵循一定的编程规范，毕竟开发的软件不是自己用，还需要和别人的集成，还需要给以后版本重用和维护。 测试的技术将在第五节进行阐述。总之流程很关键，技术也很重要，我的观点是：鱼和熊掌，两者都不能放。 四、全面质量管理 自从 Deming 的全面质量管理（ TQM ）原则在日本工业界获得了巨大成功之后，这个原则迅速被传播到了世界各个地方，同样，全面质量管理原则也被应用到了软件开发当中。如前面提到的，软件开发也是一个工程性的工作，因此必须提高整个工程的质量。产业界的大量研究（ TRW 、 Nippon Electric 和 Mitre Corp. 以及其它一些公司）表明设计活动引入的错误占软件过程中出现所有错误（和最终的缺陷）数量的 50 ％到 65 ％。根据 IBM 的研究表明，假定在分析阶段发现的错误其改正成本为 1 个单位的话，那么在测试之前（设计编码阶段）发现一个错误的修改成本约为 6.5 个货币单位，在测试时（集成测试，系统测试和验收测试）发现一个错误的修改成本约为 15 个货币单位，而在发布之后（已经交到用户手上）发现一个错误的修改成本约为 60 到 100 个货币单位。同样该比例也适用用于发现一个错误需要的时间。我们可以看下面两条曲线图： 图3 缺陷代价曲线 为了提高产品质量，缩短产品开发进度，节约产品开发成本，必须尽早的进行产品质量控制。全面质量控制要求在过程的每个阶段每个步骤上都要进行严格的验证和确认活动。 什么是验证？ 验证 就是要用数据证明我们是不是在正确的制造产品。注意这里强调的是过程的正确行【 12 】。 什么是确认？ 确认 就是要用数据证明我们是不是制造了正确的产品。注意这里强调的是结果的正确性。 IEEE 给出的验证和确认过程可以用下图来表示。验证和确认是一个广泛的概念，感兴趣的读者可以参考 IEEE Std 1012-1998 。

图4 验证和确认模型 五、关注测试 软件测试是软件质量控制中的关键活动。业界的统计数据表明，测试的成本大约占软件开发总成本的 50 ％左右。 软件测试的目的是要发现软件中的错误。一个好的测试是发现至今没有被发现的错误。传统的软件测试专注于动态测试范畴，如：单元测试，集成测试和系统测试。而测试工程的发展已经进入到了全流程的测试，包括开发过程前期的静态测试。 一般我们可以把测试分为白盒测试和黑盒测试。 白盒测试 ：顾名思义，白盒测试应当是透明的。的确，该类测试是根据程序代码的内部逻辑结构来设计测试用例进行测试。那么什么是测试用例？ 一个 测试用例 就是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。 黑盒测试 ：看了白盒测试的解释，我想你很快就能猜出黑盒测试是不考虑程序内部结构情况的。事实上也是这样。黑盒测试是根据规格说明书进行的测试。 规格说明书 记录了用户的需求。比如用户希望在编辑器中增加查找功能，那么我们把该需求写入规格说明书，根据该项要求，直接调用应用程序的该项功能进行测试，而不管其内部是用什么算法实现的。 白盒和黑盒这两类测试是从完全不同的出发点，并且是两个完全对立点，反映了事物的两个极端，两种方法各有侧重，不能替代。但是在现代测试理念中，这两种测试往往不是决然分开的，一般在白盒测试中交叉使用黑盒测试的方法，在黑盒测试中交叉使用白盒测试的方法。 常见的白盒测试是单元测试。 单元测试 是测试中最小单位的测试。简而言之，就是拿一个函数出来，加上驱动模块，桩模块，让它能够运行起来，然后设计一些用例测试其内部的控制点（如：条件判断点，循环点，选择分支点等）。 驱动模块 是模拟调用被测函数的函数。 桩函数 是模拟当前测试函数所调用的函数。 常见的黑盒测试包括：集成测试，系统测试。 集成测试 是在单元测试的基础上，将所有模块按照设计要求（如根据结构图）组装成为子系统或系统，进行集成测试。实践表明，一些模块虽然能够单独地工作，但并不能保证连接起来也能正常的工作。程序在某些局部反映不出来的问题，在全局上很可能暴露出来，影响功能的实现。 系统测试 的目的在于通过与系统的需求定义作比较，发现软件与系统定义不符合或与之矛盾的地方。系统测试的测试用例应根据需求分析说明书来设计，并在实际使用环境下来运行。系统测试的内容极其广泛，包括功能测试、协议测试、性能测试、压力测试、容量测试等等。有关测试方面的概念可以参考本人已出版的《软件测试技术概论》。 软件测试是产品最终交付到用户之前的最后一道防线，有着举足轻重的地位。然而，做好软件测试却是不容易的，一方面你需要同时掌握软件开发的技能和软件测试方面的技能；另一方面产品必须给予测试充分的独立性和资源保证。 六、成功的铁三角 在一个软件企业中，如果能够良性的发展，必须关注组织，流程和人三者之间的关系。组织是流程成功实施的保障，好的组织结构能够有效的促进流程的实施；流程对于产品的成功有着关键的作用，一个适合于组织特点和产品特点的流程能够极大的提高产品开发的效率和产品质量，反之则会拖延产品开发进度，并且质量也无法得到保证；对企业来说，人是最宝贵的财富，它们是技术的载体。对于一个软件公司来说，无论是开发人员还是测试人员，都非常关心其今后的发展通道，如果有一条清晰的技术发展线为其指明今后的职业发展方向的话，这可以大大激励员工的士气和工作积极性。另外技术发展的方向应该与现在的开发流程和规范相结合，这样有利于专业技能的提高。 总之，组织，流程和人这三者是一个企业成功的铁三角，理想的情况下它们彼此促进，糟糕的情况下它们彼此制约。 七、国际上流行的质量标准 最早进入国内的质量标准是 ISO 系列。在软件方面主要使用 ISO9000 系列标准。 ISO9000 是一个非常完整的标准，并且定义了供应商设计和交付一个有质量产品的能力所需要的所有元素。 ISO9002 涵盖了对供应商控制设计和开发活动所认为重要的质量标准。 ISO9003 用于证明供应商在检视和测试期间检测和控制产品不一致性的能力。 ISO9004 描述和 ISO9001 、 ISO9002 和 ISO9003 相关的质量标准，并提供了一个完整的质量查检表。 软件能力成熟度模型是目前国内软件企业中非常受欢迎的一个质量标准。并且该标准已经成为业界一个事实上的标准。 CMM 为软件组织提供了一个指导性的管理框架。在这个框架的指导下： ?? 软件组织可以对其软件开发、维护过程获得控制。 ?? 软件组织可以推进其软件工程更为科学、推进软件过程管理更为卓越。 ?? CMM 通过确定当前软件过程管理的成熟度，通过标识软件的质量和过程改进中关键的、要害的问题，可以指导软件组织选择正确的软件过程改进策略。 ?? CMM 将其焦点，聚焦在一系列具体的软件过程活动上，并以侵略方式（ Aggressively ）达到这些活动。一个软件组织就可以稳定地、持续地改进其整个软件组织过程，使得其软件过程管理能力取得持续地、持久地不断争长提高。 在 CMM 中，把软件工厂分为五个等级：初始级、可重复级、已定义级、管理级和优化级。其中： 初始级 ：软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，且执行没有政策、资源等方面的保证时，那么它仍然被视为初始级。 可重复级 ：人们根据多年的经验和教训，总结出软件开发的首要问题不是技术问题而是管理问题。因此，第二级的焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，可重复的过程才能逐渐改进和成熟。可重复级的管理过程包括了需求管理、项目管理、质量管理、配置管理和子合同管理五个方面；其中项目管理过程又分为计划过程和跟踪与监控过程。通过实施这些过程，从管理角度可以看到一个按计划执行的且阶段可控的软件开发过程。 已定义级： 要求制定企业范围的工程化标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程裁剪出与项目适宜的过程，并且按照过程执行。过程的裁剪不是随意的，在使用前必须经过企业有关人员的批准。 管理级 ：所有过程需建立相应的度量方式，所有产品的质量（包括工作产品和提交给用户的最终产品）需要有明确的度量指标。这些度量应是详尽的，且可用于理解和控制软件过程和产品。量化控制将使软件开发真正成为一种工业生产活动。 优化级： 的目标是达到一个持续改善的境界。所谓持续改善是指可以根据过程执行的反馈信息来改善下一步的执行过程，即优化执行步骤。如果企业达到了第五级，就表明该企业能够根据实际的项目性质、技术等因素，不断调整软件生产过程以求达到最佳。 美国国防部规定，重要性级别高的软件应该由质量级别高的企业承担。不同等级的软件公司提交的软件，其软件质量也相差很大，国外的一份统计资料如下： 表 1 、 CMM 级别与软件质量关系表格 每千行软件的缺陷数目

软件过程成熟度等级

软件准时提交的百分比

每人每月生产的程序行数

软件需要返工的百分比

平均软件失效时间（近似）

大于 10

初始级

<=50

Z

>=45

2 到 60 分钟

小于 10

可重复级

90

1.5Z

20

1-160 小时

小于 1

已定义级

99

2.5Z

10

不确定

小于 0.1

管理级

降低开发时间到 1/2

5 Z

5

不确定

小于 0.01

优化级

降低开发时间到 1/4

10Z

<=2

近似完全可靠

对于很多已经推行或者准备推行 CMM 的公司来说， CMM 的起步是很难的，因此 Humphrey 又提出了 PSP （ Person Software Process ）和 TSP （ Team Software Process ）【 2 】【 3 】。 CMM 是过程改善的第一步，它提供了评价组织的能力、识别优先改善需求和追踪改善进展的管理方式【 1 】。企业只有开始 CMM 改善后，才能接受需要规划的事实，认识到质量的重要性，才能注重对员工经常进行培训，合理分配项目人员，并且建立起有效的项目小组。然而，它实现的成功与否与组织内部有关人员的积极参加和创造性活动密不可分。 PSP 能够指导软件工程师如何保证自己的工作质量，估计和规划自身的工作，度量和追踪个人的表现，管理自身的软件过程和产品质量。经过 PSP 学习和实践的正规训练，软件工程师们能够在他们参与的项目工作之中充分运用 PSP ，从而有助于 CMM 目标的实现。 TSP 结合了 CMM 的管理方法和 PSP 的工程技能，通过告诉软件工程师如何将个体过程结合进小组软件过程，并将后者与组织进而整个管理系统相联系；通过告诉管理层如何支持和授权项目小组，坚持高质量的工作，并且依据数据进行项目的管理，向组织展示如何应用 CMM 的原则和 PSP 的技能去生产高质量的产品。 软件的生产过程及其它的许多子过程、软件的开发者和用户、以及系统的使用中存在着巨大的变化和不同，要使一个软件过程对软件生产的改善真正有所帮助，其框架应是由 CMM 、 TSP 和 PSP 组成的一个完整体系，即从组织、群组和个人三个层次进行良好的软件工程和管理实践的指导和支持。总而言之，单纯实施 CMM ，永远不能真正做到能力成熟度的升级，只有将实施 CMM 与实施 PSP 和 TSP 有机地结合起来，才能发挥最大的效力。 八、如何起步？ 质量改进需要花费成本，因此改进的途径需要视不同公司的规模、业务、财务状况、人员技术水平等多方面综合进行考虑。一般建议中型以上的较大的软件公司实施 CMM 体系。而对于一些小型的软件公司可以采取比较实际的，相对成本较少，且容易操作的方面进行，这些方面大致如下： ?? 实施简洁的开发过程体系，根据不同业务特点可以选择瀑布模型，迭代模型等，并在这些模型上进行适当的变化以适应于短平快的产品开发特点。 ?? 提高需求分析和设计方面的技术，例如：原型法技术，分析模式，设计模式，面向对象设计， UML 等； ?? 加强文档化工作。文档是经验的保留，对于一个企业要想获得长期的发展，必须加强文档化工作； ?? 加强编程规范工作； ?? 进行适当的测试工作，建议进行单元测试和系统测试； ?? 实施配置管理工作，加强版本控制； ?? 开展走读、评审和检视活动，尤其要加强代码走读，建议进行每日交叉走读活动； ?? 进行简单的度量分析获得；建议实施 PSP 活动；

什么是软件需求，什么是功能需求？——论需求的三个层次和三个方面（2）

我们的软件产品或者项目，其需求都有三个层级和三个方面。 一、我们首先看需求的三个层次软件需求包括3个不同的层次――业务需求、用户需求和功能需求。 业务需求（Business requirement）表示组织或客户高层次的目标。业务需求通常来自项目投资人、购买产品的客户、实际用户的管理者、市场营销部门或产品策划部门。业务需求描述了组织为什么要开发一个系统，即组织希望达到的目标。使用前景和范围（vision and scope）文档来记录业务需求，这份文档有时也被称作项目轮廓图或市场需求（project charter 或 market requirement）文档。功能需求（functional requirement）规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求（behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什么。注意：用户需求不总是被转变成功能需求。产品特性，所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。系统需求（system requirement）用于描述包含有多个子系统的产品（即系统）的顶级需求。系统可以只包含软件系统，也可以既包含软件又包含硬件子系统。人也可以是系统的一部分，因此某些系统功能可能要由人来承担。业务规则包括企业方针、政府条例、工业标准、会计准则和计算方法等。业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。功能需求记录在软件需求规格说明（SRS）中。SRS完整地描述了软件系统的预期特性。SRS我们一般把它当作文档，其实，SRS还可以是包含需求信息的数据库或电子表格；或者是存储在商业需求管理工具中的信息；而对于小型项目，甚至可能是一叠索引卡片。开发、测试、质量保证、项目管理和其他相关的项目功能都要用到 SRS。 除此之外，对于需求层次，我们还有其它的分法： 组织级需求->业务需求->用户需求->功能需求（有时也叫行为需求）。 组织级需求：一般代表着组织的愿景和目标。对于大的公司，一般是通过资深的咨询顾问和咨询公司得出的，呈现的方式是咨询报告。比如在ITSM或者企业信息化这方面。典型的组织级的需求是：降低成本、减少库存成本、提升IT服务部门在企业中的价值、通过ISO20000、提高IT服务的效率、提高员工的满意度等。 业务需求：是要完组织的使命，达成组织的愿景的各个业务流程和业务单元具有的需求。业务需求服从于组织需求。 用户需求：用户级的需求，是在业务级的需求下，各个岗位协作完成业务而具有的需求。我们在软件需求规格说明书中表述的需求其实主要是这一部分需求。 功能需求：同样，它代表着产品或者软件需求具备的能力。 一般是管理人员或者产品的市场部门人员负责定义软件的业务需求，以提高公司的运营效率（对信息系统而言）或产品的市场竞争力（对商业软件而言）。所有的用户需求都必须符合业务需求。需求分析员从用户需求中推导出产品应具备哪些对用户有帮助的功能。开发人员则根据功能需求和非功能需求设计解决方案，在约束条件的限制范围内实现必需的功能，并达到规定的质量和性能指标。当一项新的特性、用例或功能需求被提出时，需求分析员必须思考一个问题：“它在范围内吗？”。如果答案是肯定的，则该需求属于需求规格说明，反之则不属于。但答案也许是“不在，但应该在”，这时必须由业务需求的负责人或投资管理人来决定：是否扩大项目范围以容纳新的需求。这是一个可能影响项目进度和预算的商业决策。 二、需求的三个方面 除了功能需求外，SRS中还包含非功能需求，包括性能指标和对质量属性的描述。质量属性（quality attribute）对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括可用性、可移植性、完整性、效率和健壮性，它们对用户或开发人员都很重要。其他的非功能需求包括系统与外部世界的外部界面，以及对设计与实现的约束。还有一项称为可用性（usability）的质量属性，它规定了业务需求中“有效”（efficiently）一词的含义。约束（constraint）限制了开发人员设计和构建系统时的选择范围。约束，在产品的架构设计中，是需要被首先考虑的问题。 如果说产品的功能代表了产品的能力，那么产品的质量属性代表了产品的品质，产品的约束代表了产品必须去满足的或者适应的条件！用人说“用户体验”是产品的灵魂，对于个人级的软件这么说或许很恰当，当对于企业级甚至是行业级的产品，其灵魂有两个：一个是产品带个用户的价值，另一个是产品的品质，简单的说，就是价值和品质。但其成为一个产品的前提应该是满足约束，否则就不应该设计、开发、进入市场而成为一个垃圾。

如何通过rup用例进行需求管理的可以追踪策略

推荐用trufun sdp可以进行需求管理和对需求的追踪、变更管理。。

rup是类似于tup的一种软件开发过程管理方法。。

有什么好的需求管理工具

在这里我给大家推荐个灵活实用、专业性很强的需求管理软件（oBridge）

管理用户需求，让任务有依据

建立跟踪矩阵，让分析有基础

统御需求管理软件oBridge是一套强大的需求管理软件，它可以记录需求和它的演变过程，跟踪需求与设计、测试之间的关系，帮助用户分析需求变化造成的每一个影响， 评估需求变更造成的工作量，让需求管理不再成为项目的短板。

需求管理软件（oBridge）功能

Bridge能帮助用户实现项目需求条目化、版本化、层次化管理，建立需求跟踪矩阵，实现需求变更影响分析，并能在不同单位间实现离线数据交换。

oBridge需求管理工具实现了以下能力:

●　需求处理流程自定义

●　建立大数量级的需求跟踪矩阵

●　支持需求条目多层次关联管理

●　变更影响覆盖分析

●　需求变更后自动进行影响标记

●　需求文档合并

●　跨网路需求数据离线交换

●　支持设置角色，严格的数据权限控制

●　需求条目快速生成工作任务

●　支持需求输出到WORD和EXCEL

●　支持自定义输出样式

●　支持业务属性字段和界面的自定义

需求管理软件（oBridge）特点 ：

●　不限级别的事前变更影响分析

●　事后逐级变化通知

●　支持多文档间需求跟踪矩阵

●　支持需求处置状态跟踪矩阵

●　支持需求覆盖跟踪矩阵

●　自定义处理流程及状态

●　独立的需求条目全视图

●　支持需求文档合并

●　支持多人同时在线编辑

●　支持跟踪需求条目变化全过程

●　支持与消息、测试

需求管理软件（oBridge）优势

oBridge为企业带来以下效益：

通过快速记录和共享需求，确保用户需求都得到处置

帮助用户进行设计和测试覆盖分析，提高产品质量

通过变更影响分析，帮助用户评估变更工作量，有效控制项目边界

基于条目存储，提高复用效率，为企业需求量化管理打好基础

通过需求快速生成工作任务，合理复用需求数据

需求管理系统（oBridge）功能导航

项目功能列表

需求管理

需求管理支持版本化、条目化 管理文档和需求条目，支持自定义需求流程、数据权限控制、需求多层次关联、需求生成工作任务、建立需求跟踪矩阵、自动标记变更影响、自定义报表样式，可输出到WORD和EXCEL，支持离线数据交换。

产品管理

产品管理支持多个产品集中管理，可分版本进行管理，支持规划产品版本路线和模块，可指派到具体项目中进行落实，支持查看产品的详细信息。

如何认识需求管理

文档冲亿季，好礼乐相随mini ipad移动硬盘拍立得百度书包

的成功或失败,因此找出需求是什么,将它们记下来,进行组织,并在发生变化时对它们进行追踪,这些活动都是有意义的. 换句话说,需求管理就是：一种获取,组织并记录系统需求的系统化方案,以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程.

这个定义与 Dorfman 与 Thayer 以及 IEEE 的"软件需求工程"的定义相似.需求工程包括获取,分析,规定,验证和管理软件需求,而"软件需求管理"则是对所有相关活动的规划和控制.这里介绍的以及 IBM Rational提出的需求管理定义包括了所有这些活动.它们的区别主要在于这里选用了"管理"这个词,而不是"工程".

管理这个词更合适用来描述所有涉及到的活动,并且它准确地强调了追踪变更以保持涉众与项目团队之间共识的重要性. 对那些不熟悉"引出"这个词的人来说,它可定义为团队用来获取或发现涉众请求,确定请求后隐藏的真正需要,以及为满足这些需要对系统提出的一组适当需求.

需求管理问题一个目的在于确保系统符合人们对其期望的流程面临着哪些困难呢 当它真正在实际项目实施时,困难就暴露出来了.图 1 显示了年对开发人员,经理和质量保证人员所做的一次调查结果.该图显示了经历过最常提到的需求相关难题的受访者比例.

5．下面列出了更多与需求有关的问题:

需求不总是显而易见的,而且它可来自各个方面. 需求并不总是容易用文字明白无误地表达. 存在不同种类的需求,其详细程度各不相同. 如果不加以控制,需求的数量将难以管理. 需求相互之间以及与流程的其他可交付工件之间以多种方式相关联. 需求有唯一的特征或特征值.例如,它们既非同等重要,处理的难度也不同. 需求涉及众多相关利益责任方,这意味着需求要由跨职能的各组人员来管理. 需求发生变更. 需求可能对时间敏感. 当这些问题与需求管理和处理技能不足以及缺乏易用工具等情况一同出现时,许多团队都对管理好需求不抱希望了.IBM Rational 已经开发出指导团队提高需求管理技能和流程的专业技术,并使用相应的工具使得上述的流程和专业技术得以实现.

需求捕获，从上述的分析可以看出,需求的捕获是需求管理的基础和前提.在这里,将介绍一种为业界所广泛采用并经验证的需求捕获方法,即用例模

型. 用例模型是系统既定功能及系统环境的模型,并作为客户和开发人员之间的契约.用例模型用作分析,设计和测试活动的基本输入.用例是贯穿整个系统开发的一条主线.同一个用例模型即为需求工作流程的结果,可当作分析设计工作流程以及测试工作流程的输入使用.参与者(Actor)和用例(UseCase)是用例模型中的主要元素. 下图显示了自动取款机系统用例模型的一部分:

客户 查询 提款 转帐

客户身份验证系统时钟 数据库服务器 (from )系统维护 信函打印机 打印对帐单

用例图用于显示包含参与者和用例的用例模型示例.系统建模有许多种方法,每种建模方法可以满足不同的目的.然而,用例模型最重要的作用是将系统行为传达给客户或最终用户.可能与该系统交互的用户和任何其他系统都是参与者.由于参与者代表了系统用户,它们协助界定系统并提供十分明确的系统用途说明.编写用例依据参与者的需求来进行.这样就确保该系统成为用户期望得到的系统.

参与者和用例都是通过将客户需求及潜在用户当作重要的信息查找到的.找到这些用例和参与者后,应对它们作简要说明.在详细说明这些用例之前,客户应复审该用例模型以核实所有的用例和参与者都已经找到,并且它们可以提供客户所需要的东西. 在迭代开发环境中,您可以选择用例的子集以便在每个迭代中详细描述.参与者和用例找到后,需要详细说明每个用例的事件流.这些说明指出系统与参与者交互的方式以及在各个独立用例中系统执行的有关操作.

最后,对已完成的用例模型(包括用例说明)进行复审,开发人员和客户使用该模 型对系统应执行的操作达成一致意见. 二、需求管理模型

在需求管理的流程中,需求的捕获手段固然重要,但在需求的捕获和需求最终成型的过程中,我们会面临各种和需求相关的信息和资料(也可以把这些信息笼统地称做"需求"),如何发现这些信息之间的关系并有效组织,更为关键. 需求类型 在RUP中,我们采用一种金字塔方式的管理办法,来组织和管理我们获取的信息乃至最终的需求.为了建立一个真正满足客户需求的系统,项目团队首先必须确定系统要解决的问题.然后,团队必须确定涉众,从中获得业务和用户需要,对其进行描述,并区分它们的优先级.从这一组高层期望或需求出发,对产品或系统特性集达成一致意见.而后,由产品特性来抽取软件需求,在我们的模型中,软件需求是以用例模型的方式来描述.从测试的角度来看,测试项一定来自于软件需求,即软件需求中确定了哪些需求项,测试就要根据这些需求项来制定和实现. 系统越大越复杂,出现的需求类型就越多.一个需求类型不过是指需求的一个类.通过确定需求类型,团队可以把大量需求组织成意义明确且更容易管理的组.在一个项目中建立不同类型的需求有助于团队成员对变更请求进行分类,并使相互之间的沟通更为清楚明确.从上述的分析中我们可以看到,通常,一类需求可以细分即分解成其他类型的需求.这里,我们就把需求分解为几种类型,并在他们之间建立相应的关联.业务规则和前景声明包括高层次的需求,团队可以从中导出用户需要,特性和产品需求类型.用例和其他建模形式驱动设计需求,该需求可分解为软件需求,并可以用分析设计模型来说明.测试需求源于软件需求,它被分解为具体的测试过程.如果既定项目中有成百上千个,甚至上万个需求实例时,对需求进行分类可以使项目更容易管理.上述的这些需求类型同时保存在对应的RUP文档和数据库中. 三、应用需求类型

通过定义需求类型,以及他们之间的关系,我们就建立了一个需求管理模型的框架.当然,我们建立这样的一个模型,是为了方便我们使用需求,为了达到这一目的,我们还需要在此基础上添加相应的内容. 需要对各种需求类型添加它们的属性,以便于对需求进行查询等管理手段.比如,可以针对用户需要,确定该需要的必要性,优先级,确定性等属性.在实际的项目中,就可以确定这些属性的值,而后根据这些实际属性值来安排项目的进度表等.或是在项目进度紧急时,确定哪些需求是可以延期完成,而哪些是必须完成的,等等. 需求的追踪性.其次,可

以根据不同需求的导出情况,在不同的需求之间建立追踪关系.譬如,用户需要决定了要构建产品的特性,产品的特性又决定了产品的软件需求,等.在这些不同类型的需求之间建立关联,一旦其中的某些需求发生变化,就可以确定它可能带来的影响,从而制定相应的策略. 四、需求管理的工作流程 1．工作流明细简介 问题分析

问题分析可以通过了解问题及涉众的最初需要,并提出高层解决方案来实现.它是为找出"隐藏在问题之后的问题"而进行的推理和分析.问题分析期间,将对"什么是面临实际问题"和"谁是涉众"等问题达成一致.而且,您还要从业务角度界定解决方案,以及制约该解决方案的因素.您应该已经对项目进行过商业理由分析,这将便于您更好地预计能从构建中的项目中得到多少投资回报. 2．理解涉众需要

需求来自各个方面,比如来自客户,合作伙伴,最终用户或是某领域的专家.您需要掌握如何准确判断需求应来源于哪方面,如何接近这些来源并从中获取信息.提供这些信息主要出处的个人在本项目中称为涉众.如果您正在开发一个在您公司内部使用的信息系统,那么在开发团队中应包括具有最终用户经验和业务领域专业知识的人员.通常讨论将在业务模型这一级上展开,而不是在系统这一级上展开.如果正在开发一个要在市场上出售的产品,那么您可以充分调动营销人员,以便更好地了解该市场中用户的需要. 获取需要的活动可使用这样一些技巧:访谈,集体讨论,概念原型设计,问卷调查和竞争性分析等.获取结果可能是一份图文并茂的请求或需要列表,并按相互之间的优先级列出. 3．定义系统

定义系统指的是解释涉众需求,并整理为对要构建系统的意义明确的说明.在系统定义的初期要确定以下内容:需求构成,文档格式,语言形式,需求的具体程度(需求量及详细程度),需求的优先级和预计工作量(不同人在不同的实践中通常对这两项内容的看法大不相同),技术和管理风险以及最初规模.系统定义活动还可包括与最关键的涉众请求直接联系的初期原型和设计模型.系统定义的结果是用自然语言和图解方式表达的系统说明.

4．管理项目规模

为使项目高效运作,应仔细根据所有涉众的需求确定优先级,并对项目规模进行管理.有的开发人员仅仅重视所谓的"复活节彩蛋"(即开发人员感兴趣或觉得有挑战性的特性),而不是及早将精力投入降低项目风险或提高应用程序构架稳定性方面,这已使太多的项目蒙受损失.为确保尽早解决或降低项目中的风险,应以递增的方式开发系统.要慎重选择需求,以确保每次增加都能缓解项目中的已知风险.要达到目的,您需要和项目的涉众协商每次迭代的范围.通常,这要求具备管理项目各个阶段的期望结果的良好技能.

除了控制开发过程本身,您还需控制需求的来源,并控制项目可交付工件的外观. 改进系统定义 系统的详细定义应能让涉众理解,同意并认可.它不仅需要具备所有功能,而且应符合法律或法规上的要求,符合可用性,可靠性,性能,可支持性和可维护性.感觉构建过程复杂的系统就应该有复杂的定义,这是一种常见的错误看法.这会给解释项目和系统的目的造成困难.人们可能印象深刻,但他们会因不甚理解而无法给出建议.应该致力于了解您制作的系统说明文档的读者.您可能常会发现需要为不同的读者准备不同的说明文档.

我们认为用例方法是传达系统目的和定义系统细节的一种行之有效的方法,它常与简单的可视化原型结合使用.用例有助于为需求提供一个环境,利用它可生动地说明系统使用的方式. 系统详细定义的另一个构件是说明系统采用的测试方式.测试计划及要执行测试的定义将会说明要核实哪些系统功能. 五、管理需求变更

定义需求时无论怎样谨慎小心,也总会有可变因素.变更的需求之所以变得难以管理,不仅是因为一个变更了的需求意味着要花费或多或少的时间来实现某一个新特性,而且也因为对某个需求的变更很可能影响到其他需求.应确保赋予需求一个有弹性的结构,使它能适应变更,并且确保使用可追踪性链接可以表达需求与开发生命周期的其他工件之间的依赖关系.管理变更包括建立基线,确定需要追踪的重要依赖关系,建立相关项之间的可追踪性,以及变更控制等活动.

软件需求管理这本书怎么样

作者采用一种非形式化、易于接受的风格，讲述他们自己的实战经历，并通过大量的个例研究，向我们展示了设计和开发人员如何把用例技术和传统的软件表达形式相结合，高效地确定需求。书中还介绍了一些经过实践证明的用以确定、实现和确认需求的技术。

书中给出了在整个项目生命周期中，管理需求的六大团队技能；分析问题，理解用户需要，定义系统，管理范围，细化系统定义和构建正确的系统。本书特别强调不断地管理变更，描述了一个过程，确保成功定义项目范围，并使所有涉众达成共识。 书中讨论的主要问题包括： ·问题分析的五个步骤 ·业务建模和系统工程 ·从客户和涉众那里启发需求的技术 ·建立和管理项目范围 ·应用和细化用例 ·产品管理 ·从需求到设计和实现的过渡 ·从用例到测试用例的过渡 ·敏捷需求方法

需求获取的常用方法有哪些？25.说明软件测试和调试的目的有何区别

需求获取的常用方法有哪些

1）用户访谈

用户访谈是一种最基本的需求获取手段，它是指分析人员以个别访谈或小组合议的形式与用户进行初步的沟通。用户访谈的形式包括结构化和非结构化两种，结构化是指分析人员按照——定准则事先准备好一系列问题，通过用户对问题的回答来获取有关目标软件方面的内容；非结构化则是只列以一个粗糙的想法，根据访谈的民体情况来进行发挥。

2）用户调查

在进行用户防谈时，由于很多关键人员的时间有限，不易安排过多的时间或者项日涉及的客户面较广。不可能——一访谈。因此，就需要借助用户调杏的方法，通过精心设计要问的问题，然后下发到相关的人员手中，让他们填写，再从所填写的内容中获取系统的需求倍息，这样就可以克服上述的问题。

用户调查最大的不足就是缺乏灵活性，而且可能存在受调查人员不能很好表述自己想法的限制。

3）现场观摩

俗话说，百闻石如一见，对于许多较为复杂的流程和系统而言，是很难用自然语言表达清楚的。因此，为了能够对系统的需求获得全面的了解，实际观察用户的操作过程就是一种行之合效的方法。现场观摩就是走到客户的工作场所，一边观察，一边听客户讲解，甚至可以安排人员跟随用户一起工作一段时间。这样就可以使得分析人员对客户的需求有更加直观的理解。但是，在现场观摩过程中必须切记；建造软件系统不仅仅只是为了模拟客户的手下操作过程，还必须将最好的经济效益、最快的处理速度、最合理的操作流程和最友好的用户界而等作为软件设计的目标。

4）文档考古

文档考古是指对历史存在的—些文档进行研究，从带有数据的文件、表单、报表等文档中获取所需信息的过程。对于一些数据流程比较复杂的、工作表单较多的项目来说，就可以应用这种方法。

5）建立联合分析小组

在系统开发时，系统分析员和用户之间由于知识结构的差异，难免存在难逾越的交流鸿沟。

用广提供的需求信息，在系统分析员看来可能是零散和片面甚至无法理解的。因此，为了能够减少交流上的问题，就需要一个领域专家来帮助进行沟通，即可以建立一个由用户、系统分析员和领域专家参加的联合分析小组来共同完成需求的获地。

6）原型法

原型是在软件开发中被广泛使用的一种工具，在软件系统的很多开发阶段都起着非常重要的作用。原型法就是尽可能快地建造一个祖糙的系统，这系统实现了目标系统的某些或全部功能，但是这个系统可能在可靠性、界面的友好性或其他方向上存在缺陷。建造这样一个系统的目的是为了看，考察某一方面的可行性。如算法的可行性，技术的可行性，或考察是否满足用户的需求等。原型是在最终系统产生之前的一个局部真实表现，可以让人们能够对一些具体问题进行基于文物的有效沟通，从而帮助人们尽早解决软件开发个存在的各种不确定性。

7）模型驱动

前面的面谈、原型、观察以及文档审查等方法可以通过执行一些具体的获取行为来对系统需求进行认知和理解。但是大多数软件系统，尤其是对于复杂的系统而言，它们的需求获取任务绝不是可以通道一两次这样简单的获取行为就能够完成的。为了能够使得获取行为相互配合、减少不必要的精力耗费和防止出现获取信息的遗漏，可以采用模型驱动的方法。

8）基于上下文的方法

软件系统是作为一个整体存在的，它通过和环境的交互来解决用户的问题，满足用户的需求。软件系统中的每项功能都是依存于一定的背景和上下文环境，因此，要正确地理解系统的功能就必须要正确地理解它的背景和上下文知识。基于上下文的方法就是注重于系统的环境、开发组织的业务背景、涉众的特征以及目标等。与前面的方法相比，它更加注重用户在—定环境下表现出来的行为，通过分析用户的行为得到信息。

说明软件测试和调试的目的有何区别

1、目的不同

软件测试的目的是发现错误，至于找出错误的原因和错误发生的地方不是软件测试的任务，而是调试的任务.调试的目的是为了证明程序的正确，因此它必须不断地排除错误.它们的出发点不一样。前者是挑错，是一种挑剔过程，属于质盘保证活动。后者是排错，是一种排除过程，是编码活动的一部分.

2、任务不同

既然软件测试属于质量保证活动，因此它贯穿于整个开发过程.从需求分析开始，就要制订软件测试计划，软件设计时要设计系统软件测试、集成侧试用例，编码阶段要设计单元软件测试用例并进行单元软件测试，软件测试阶段要进行集成软件测试、系统软件测试等，直到产品交付。只要有修改就有软件测试，产品交付后同样。它是比较有规律的活动，有系统的方法、原则作指导。

而调试是编码活动的一部分，因此有编码就有调试.它的任务主要就是排错。调试的方法经常与使用的开发工具有关，例如:解释型的开发工具可以交互式调试，编译型开发工具就很难较好地查错。当然它有一些启发式的方法，它是一种比较依赖开发人员经验的活动。

3、指导原则和方法不同

软件侧试是一种有规律的活动，有一系列软件软件测试的原则.其中主要是制订侧试计划，然后严格执行.其次是一种挑剔性行为，因此它不但要侧试软件应该做的，还需要侧试软件不应该做的事情。调试所遵循的规律主要是一些启发式规则，是一个推理过程。例如使用归纳法、演绎法、回溯法等。

软件测试的输出是预知的，其软件测试用例必须包括预期的结果，而调试的输出大多是不可预见的，需要调试者去解释、去发现产生的原因。

4、操作者

因为心理状态是软件测试程序的障碍，所以执行软件测试的人一般不是开发人员，以使软件测试更客观、更有效，而调试人员一般都是开发人员.

如何进行需求管理

　　需求管理源于业务需要，始于需求挖掘，继而需求分析，需求定义，需求验证。周而复始。

　　一，业务需要说明需求产生的原因，可能是高层制定的目标，中层对工作流程的调整，基层碰到无法解决的问题，用户需要，外部环境变化，竞争对手策略变化或者政府政策调整等。

需求人员在明确业务需要时，首先明确干系人，其次获取干系人要求/需求。可以采用的方法包括：行业基准（竞品），业务规则分析（产品分析），头脑风暴，焦点小组，功能分解，根源分析等。

二，需求挖掘阶段的目标是找出干系人的真实需求。单方面的口头描述或者规范章程都可能与实际需求相差甚远，因此需要需求人员收集各方面需要，交叉验证，合理推导，发掘出用户的实际需求。

工作步骤：确认干系人，收集实际情况，整合多方面信息，确认实际需要。方法包括：访谈，观察，问卷，焦点小组，头脑风暴，可用性测试，竞品分析，数据分析，文档分析，咨询专家等。

三，需求分析阶段则是对已经收集的真实需求进行规整，包括两部分内容，组织整理需求和对需求排优先级。

组织整理需求采用相同粒度描述需求，并描述需求间关系。主要方法包括：功能分解，业务规则分析，数据模型，流程模型，范围模型，用户经历，场景和用例，组织模型。

需求优先级划分通过定义需求的优先级，为计划安排提供有价值的参考。可以参考的定义维度包括：时间，预算，业务价值，业务和技术风险，实施难度，成功可能性，规范和政策，与其他需求的关系，与干系人的协议，紧急程度等。可采用3/4级优先级定义，或者MoSCoW模型定义，其中M=必须 S=应该 C=能够W=将要。

四，需求定义主要工作为根据前期整理的相关文档整理需求说明。输出包括：业务需要，需求陈述，组织整理后的需求以及需求优先级。需求说明主要包括：业务需要，业务需求和系统需求。·

五，需求验证包括需求检验和需求确认，即需求过程中的检查和需求完成的测试。

需求跟踪矩阵是个好东西，可以在需求分析阶段产出。

转载请注明出处51数据库 » 软件需求管理用例方法第二版 如何加强软件需求管理提高软件质量