| 词条 | 需求管理 |
| 释义 | § 需求管理的过程 从需求获取开始贯于整个项目生命周期，力图实现最终产品同需求的最佳结合。通过对需求管理在项目进程中实施的不同任务进行分析，我们可以看出需求理所起的作用。 需求管理本就是一个动态的过程，离开了能动的、变化的系统进程而空谈需求管理，无异于纸上谈兵。需求管理恰如裁缝的量体裁衣，它直接关系到最终产品的成型。仅从字面出发，如果一个产品满足了客户需求，那它无疑就是成功的。需求管理的过程，从需求分析开始贯穿整个项目始终，力图最终产品同需求性的最佳结合（参见Figure 1）。通过对需求管理在项目进程中实施的不同任务进行分析，我们可以看出需求管理所起的作用。 需求管理能够确证： ●我们确知客户的需求是什么（质量）； ●满足客户需求的最佳解决办法（统一性）； 著名学者Crosby对于质量的定义是"同需求保持统一"。从这个意义上说，需求管理正是从质量出发以确定需求。每个人都应当始终明白他们所做的具体任务其意义何在。然而，在一个产品的生命周期里，其需求性是能动的，是处于变化之中的。 对于系统工程没有严格统一的定义，因此很难找到足够的数据以说明系统工程所起的作用。有些致力于研究需求分析的组织认为，一项开发计划应当至少将8-15%的资源投入到系统工程方面。如果低于这一标准，将很可能导致无法对客户群做出准确把握。如果该项开发计划含有许多创新或实验的成分，那么这一百分比还应当适度提高。 定义需求（Define Requirement） 在项目进展过程中，如何区分用户需求与需求分析中需求定义呢？ 当完成用户需求调查后，首先对《用户需求说明书》进行细化，对比较复杂的用户需求进行建模分析，以帮助软件开发人员更好地理解需。例如采用Rational 的Rose工具进行需求的建模分析。如果使用工具进行建模分析，对需求分析人员的要求比较高。 当完成需求的定义及分析后，需要将此过程书面化，要遵循既定的规范将需求形成书面的文档，我们通常称之为《需求分析说明书》。 邀请同行专家和用户（包括客户和最终用户）一起评审《需求规格说明书》，尽最大努力使《需求规格说明书》能够正确无误地反映用户的真实意愿。需求评审之后，开发方和客户方的责任人对《需求规格说明书》作书面承诺。具体的同行评审详见需求评审章节。 需求确认(Requirement Validate) 需求确认是需求管理过程中的一种常用手段，也是需求控制的五一节之一；确认有两个层面的意思，第一是进行系统需求调查与分析的人员与客户间的一种沟通，通过沟通从而对需求不一致的进行剔除；另外一个层面的意思是指，对于双方达成共同理解或获得用户认可的部分，双方需要进行承诺。 建立需求状态 何谓需求状态；顾名思义，状态也就是一种事物或实体在某一个时刻或点所处的情况，此处要讲的需求状态是指用户需求的一种状态变换过程。 为什么要建立需求状态？在整个生命周期中，存在著有几种不同的情况，在需求调查人员或系统分析人员进行需求调查时，客户存在的需求可能有多种，一类是客户可以明确且清楚的提出的需求；一类是客户知道需要做些什么，但又不能确定的需求；另一类是客户本身可以得出这类需求，但需求的业务不明确，还需要等待外部信息。还有是客户本身也说不清楚的。 对于这些需求，在开发进展的过程中，存在著以下几种情况: 有可能要取消的 有的因为不明确而可以后延的，同时可能转化为被取消的需求 与客户经过沟通或确认的，此处有两种情况，一类是确认双方达成共识，另一种情况是还需要再进一步沟通的。 下面是一个简单的状态例子： CLOSED：经过确认，双方认可并达成共识； OPEN:双方确认，但没有达成共识的需求； 待定：客户提出需求，但双方没有经过沟通或确认； 需求评审(Requirement Review) 对工作产品的评审有两类方式，一类是正式技术评审，也称同行评审，另一类是非正式技术评审。对于任何重要的工作产品，都应该至少执行一次正式技术评审。在进行正式评审前，需要有人员对其要进行评审的工作产品进行把关，确认其是否具备进入评审的初步条件。 需求评审的规程与其它重要工作产品（如系统设计文档、源代码）的评审规程非常相似，主要区别在于评审人员的组成不同。前者由开发方和客户方的代表共同组成，而后者通常来源于开发方内部。 有人问：需求评审究竟评审什么？要细到什么程度？怎么样进行？ 严格地讲，应当检查需求文档中的每一个需求，每一行文字，每一张图表。评判需求优劣的主要指标有：正确性、清晰性、无二义性、一致性、必要性、完整性、可实现性、可验证性、可测性。如果有可能，最好可以制定评审的检查表。 需求评审面临的困难及对策如下： 需求评审的一个通病是“虎头蛇尾”。需求评审的确乏味，也比较费脑子。刚开始评审时，大家都比较认真，越到后头越马虎。当需求文档很长时，几乎没人能够坚持到最后。会议主持人事先要强调需求评审的重要性：认真评审一小时可能会避免将来数十天的“返工”，让大家足够重视。评审组长还要设法避免大家在昏昏沉沉中评审。如果评审时间比较长，建议每隔两小时休息一次。另外，如果系统比较大，也可以细分成不同的部分分别进行，严格控制每一次评审的文档规模及持续时间。 需求评审涉及的人员可能比较多，有些时候让这么多人聚在一起花费比较长的时间开会并不容易（例如有些人可能出差在外，有些人可能事务缠身）。没有必要把所有事情挤在一块做，需求开发是循序渐进的过程，需求评审也可以分段进行。这样每次评审的时间比较短，参加评审的人员也少一些，组织会议就比较容易。对于需求的工作产品《需求规格说明书》，我们可以标明几种文档状态，如草稿状态。评审状态，初始状态等。只有进入评审状态时，我们可以用不同的方式来对文档进行评审。但当其评审状态转化为初始状态时，需要进行严格的正式的同行评审。 开评审会议时经常会“跑题”，导致评审效率很低。有时话匣子一打开后关不上，大家越扯越远，结果评审会议变成了聊天会议。主持人应当控制话题，避免大家讨论与主题无关的东西。对于自主研发的产品，由于需求评审人员大部分是开发人员，大家会不知不觉地谈论软件“如何做”。由于需求是否“可实现、可验证、可测试”本来就属于需求评审的范畴，所以强制大家“只谈做什么，不谈怎么做”几乎是不可能的。那么，在需求的评审会上，需要允许开发人员谈如何做，但不需太细，适而可止。同时，评审会必须明确一位评审组长，对时间与问题进行控制。 开评审会议时经常会发生争议。适当的争议有利于澄清问题，比什么东西都一致赞成要好。然而当争议变为争吵时就坏事了。争吵不仅对评审工作没有好处，而且会无意中伤害同事们的感情。同时也解决不了问题。所以，在评审会的过程中，我们要尽可能的是在阐述事实与证据，而并不是从你心底要如何地说服别人。 人们在很多时候分不清楚自己究竟是“坚持真理”还是“固执己见”。毫不妥协或者轻易妥协都不是好办法。我们应当养成良好的习惯：不要一棍子打死异己的观点，尝试着让自己站在他人的立场思考问题，这样你会找到比较满意的答案。试著从不同的角度去看同样的问题。 {项目名称}评审报告_需求 基本信息 工作产品.版本号 名称，标识符，版本，作者，时间 工作产品标识号 评审方式 第几次评审 工作产品存放路径 评审地点 评审时间 参与人员 评审人员名字 工作单位或部门 职务职称 签字 问题记录及处理意见 问题编号 位置 问题描述 问题类型 严重程度 Problem A Problem B 评审结论 评审结论 【 】 工作产品合格，“无需修改”或者“需要轻微修改但不必再审核”。 【√】 工作产品基本合格，需要作少量的修改，之后通评审组长检查即可。 【 】 工作产品不合格，需要作比较大的修改，之后必须重新对其评审。 签字 需求承诺（Requirement Consent） 什么是需求承诺，是指开发方和客户方的责任人对通过了同行评审的需求阶段的工作产品，作出承诺，同时该承诺具有商业合同的同等效果。 需求承诺如下： 需求承诺 XXX项目需求文档_《XXX需求说明书》，版本号：X.X.X,是建立在XXX与XXX双方共同对需求理解的基础之上，同意后续的开发工作根据该工作产品开展。如果需求发生变化，双方将共同遵循项目定义的“变更控制规程”执行。需求的变更将导致双方重新协商成本、资源和进度等。 甲方签字 乙方签字 不少人会草率地??面签字吗，反正已经评审过了，我就签吧。但他将来变更需求时可能会表示不瞒：“不错，我是签字了，但是我并没有阅读文档。是你们要我在文档上签字的，我是相信你们才这么做的。”为了避免发生此类纠纷，人们在作出承诺之前务必要认真阅读文档，一定要明白签字意味着什么。 需求跟踪(Requirement Track) 为什么要进行需求跟踪？在整个开发过程中，进行需求跟踪的目的是为了建立和维护从用户需求开始到测试之间的一致性与完整性。确保所有的实现是以用户需求为基础。对于需求实现是否全部的覆盖。同时确保所有的输出与用户需求的符合性。 需求跟踪有两种方式，正向跟踪与逆向跟踪： 正向跟踪：以用户需求为切入点，检查《用户需求说明书》或《需求规格说明书》中的每个需求是否都能在后继工作产品中找到对应点。 逆向跟踪：检查设计文档、代码、测试用例等工作产品是否都能在《需求规格说明书》中找到出处。 正向跟踪和逆向跟踪合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护《需求跟踪矩阵》。需求跟踪矩阵保存了需求与后续开发过程输出的对应关系。矩阵单元之间可能存在“一对一”、“一对多”或“多对多”的关系。见下表：简单的需求跟踪矩阵示例。 需求代号需求规格说明书V1.0设计文档V1.2代码1.0测试用例测试记录 R001标题或标识符标题或标识符代码文件名称 测试用例标识或名称 R002……… … ………… … § 简单的需求跟踪矩阵示例1 使用需求跟踪矩阵的优点是很容易发现需求与后续工作产品之间的不一致，有助于开发人员及时纠正偏差，避免干冤枉活。 很多人有这样的误解：如果依照“需求开发－系统设计－编码－测试”这样的顺序开发产品，由于每一步的输出就是下一步的输入，所以不必担心设计、编程、测试会与需求不一致，因此可以省略需求跟踪。那么，需要指正的是，按照软件生命周期严格线性顺序的开发模型并不能保证各个开发阶段的工作产品与需求保持一致。因为开发者是人而不是机器。而且，大多数开发人员也都深有体会。 生活中“以讹传讹”的例子，想必大家都很熟悉。学生甲在精工实习时被机器弄破了手指，于是到医院包扎。同学乙路过医院时看到甲的手血迹斑斑，以为甲的手指被机器割断，于是将这个坏消息告诉同学丙。丙急忙转告同学丁，说甲的手被机器割断，正躺在医院里。丁十万火急地告诉全班同学，大家陷入悲痛之中，都以为“甲的胳膊被机器割断了，正躺在医院里，人快不行了。” 由于人们的表达能力、理解能力不可能完全相同，人与人之间的协作很难达到天衣无缝的境界。而使用需求追溯的本身也是一种传递的过程。 需求追溯本身并不是一件复杂的事，而是我们的本身一种理念在支配著我们。也许就有人认为这本身就是在浪费时间，主要麻烦是，当需求或工作产品发生变更时，开发人员要及时更新需求跟踪矩阵。然而没想到的事，如果后来再花时间来做同样的事的时候，将会付出更多。也时也就丢去了本身做这件事的意义。 § 需求变更控制(Requirement Change Control) 需求变更通常会对项目的进度、人力资源产生很大的影响，这是开发商非常畏惧的问题。也是必须面临与需要处理的问题。作为软件项目，特别在外地实施的工程软件项目而言，需求发生若干次变更似乎是不可避免的。需求发生变更的起因主要有： 随著项目生命周期的不断往前推进，人们（包括开发方和客户方）对需求的了解越来越深入。原先的提出的需求可能存在著一定的缺陷，因此要变更需求。 市场业务需求发生了变化，原先的需求可能跟不上当前的市场业务发展，因此要变更需求。由于市场变化而导致需求发生变更，开发商大可不必为此烦恼，应当高兴才对。倘若市场静如死水，那么开发商吃了“上一顿”就没有“下一顿”。正因为市场在变化，才会产生更多商机，聪明的开发商才会有活干，有钱赚。 如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。毫无疑问，这种需求??方工作失误造成的，双方应当好好反省，认真学习需求开发和管理的方法，避免再犯相似的错误。 总的而言，人们提出需求变更，本就是出于能够是产品更加符合市场或客户需求，出发点本身是好的。但对于开发小组而言，需求的变更则意味着要需要重新进行估计，调整资源、重新分配任务、修改前期工作产品等，而作为开发商，需要增预算与投资，开发组要为此付出较重的代价。假定每次需求变更请求都被接受的话，那么这个项目将会成为一个连环式的工程。 § 需求变更控制的动机是： 如果需求变更带来的好处大于坏处，那么允许变更，但必须按照已定义的变更规程执行，以免变更失去控制。 如果需求变更带来的坏处大于好处，那么拒绝变更。 当然，好处与坏处并不是主观的，而是通过客观的分析与评价而得出的。 对于需求的变更，在某一个程度上来说，也就是项目的范围进行了变化。而需求同时又是项目进行的基础。是非常得要的基石。通常对于需求的变更需要客户与开发方共同参与，包括负责人及市场人员。当然，我们需要根据变更的内容来灵活运用。 需求变更控制过程中最难办的事情是莫过于“拒绝客户提出的需求变更请求”。客户会想当然地以为变更需求是他的权利，因为他付钱给开发方。通常情况下开发方是不敢得罪客户的，但是无原则地退让将使开发小组陷入困境。怎么解决这个问题呢，通常情况下，每一类“游戏”都有一定的游戏规则，那么我们事先也需要建立“游戏规则”。 如果事先没有“游戏规则”的话，开发方的负责人需要一些社交技巧来减缓矛盾。例如首先承认客户提出的需求变更请求是合理的，再阐述己方的难处，最后建议在开发该产品新版本时修改需求。这种方式比直接拒绝有效得多，既不得罪客户，又为自己争取了余地。 另外还有一种方法，可以将变更需求先进行记录，并通知给客户，当其需求变化在开发组不能接受的范围时，可以通过市场进行相关的协调。 需求变更本是正常的，并不可怕，可怕的是需求的变更得不到控制。 从上述的分析可以看出,需求的捕获是需求管理的基础和前提.在这里,将介绍一种为业界所广泛采用并经验证的需%E4%BE%8B%E6%A8%A1%E5%9E%8B 求的一个类.通过确定需求类型,团队可以把大量需求组织成意义明确且更容易管理的组.在一个项目中建立不同类型的需求有助于团队成员对变更请求进行分类,并使相互之间的沟通更为清楚明确.从上述的分析中我们可以看到,通常,一类需求可以细分即分解成其他类型的需求.这里,我们就把需求分解为几种类型,并在他们之间建立相应的关联.业务规则和前景声明包括高层次的需求,团队可以从中导出用户需要,特性和产品需求类型.用例和其他建模形式驱动设计需求,该需求可分解为软件需求,并可以用分析设计模型来说明.测试需求源于软件需求,它被分解为具体的测试过程.如果既定项目中有成百上千个,甚至上万个需求实例时,对需求进行分类可以使项目更容易管理.上述的这些需求类型同时保存在对应的RUP文档和数据库中. § 应用需求类型 通过定义需求类型,以及他们之间的关系,我们就建立了一个需求管理模型的框架.当然,我们建立这样的一个模型,是为了方便我们使用需求,为了达到这一目的,我们还需要在此基础上添加相应的内容. 需要对各种需求类型添加它们的属性,以便于对需求进行查询等管理手段.比如,可以针对用户需要,确定该需要的必要性,优先级,确定性等属性.在实际的项目中,就可以确定这些属性的值,而后根据这些实际属性值来安排项目的进度表等.或是在项目进度紧急时,确定哪些需求是可以延期完成,而哪些是必须完成的,等等. 需求的追踪性 其次,可以根据不同需求的导出情况,在不同的需求之间建立追踪关系.譬如,用户需要决定了要构建产品的特性,产品的特性又决定了产品的软件需求,等.在这些不同类型的需求之间建立关联,一旦其中的某些需求发生变化,就可以确定它可能带来的影响,从而制定相应的策略. |
| 随便看 |
百科全书收录594082条中文百科知识，基本涵盖了大多数领域的百科知识，是一部内容开放、自由的电子版百科全书。