第4章 需求开发与需求管理
目录
第4章需求开发与需求管理 (3)
4.1 什么是需求 (4)
4.1.1基本概念 (4)
4.1.2需求案例 (4)
4.2 了解用户 (6)
4.3 需求工程 (7)
4.3.1基本概念 (7)
4.3.2一些感悟 (8)
4.4 需求开发的主要困难与对策 (9)
4.4.1知识技能问题 (9)
4.4.2态度问题 (10)
4.4.3合作关系 (10)
4.4.4用户说不清楚需求 (12)
4.4.5双方误解需求 (12)
4.4.6开发人员写不好需求文档 (13)
4.4.7用户经常变更需求 (13)
4.5 如何开展需求调查 (13)
4.5.1需求调查规程 (13)
4.5.2准备调查 (14)
4.5.3调查与记录 (14)
4.5.4撰写用户需求说明书 (15)
4.6 如何进行需求分析 (17)
4.6.1问答分析法 (17)
4.6.2建模分析法 (17)
4.6.2.1 结构化分析法 (18)
4.6.2.2 面向对象分析法 (18)
4.6.2.3 恰当地使用图形符号 (19)
4.6.3作出决策 (19)
4.7 什么是好的产品需求规格说明书 (20)
4.7.1正确 (20)
4.7.2清楚 (20)
4.7.3无二义性 (20)
4.7.4一致 (21)
4.7.5必要 (21)
4.7.6完备 (21)
4.7.7可实现 (22)
4.7.8可验证 (22)
4.7.9确定优先级 (22)
4.7.10阐述“做什么”而不是“怎么做” (23)
4.8 如何定义产品需求 (23)
4.8.1规程 (23)
4.8.2软件需求规格说明书的模板 (24)
4.9 需求确认 (26)
4.9.1规程 (26)
4.9.2需求评审 (26)
4.9.3需求承诺 (28)
4.10 需求跟踪 (29)
4.11 需求变更控制 (30)
4.12 CMMI对应规范 (32)
4.12.1需求开发过程域的目标与实践 (32)
4.12.2需求管理过程域的目标与实践 (33)
4.13 需求建模工具 (33)
4.14 需求管理工具 (34)
4.15 应用示例 (34)
4.15.1成功的示例 (34)
4.15.2失败的示例 (34)
4.16 小结 (34)
第4章需求开发与需求管理
我们把所有与需求直接相关的活动通称为需求工程。需求工程是国内大学软件工程教育最薄弱的环节之一，这种教育模式下诞生的软件工程师会有这样的习惯：他们在开发产品时并不清楚究竟该做什么，但却在一直忙碌不停地开发。
这不是个别的荒唐现象，这差不多成了国内软件业的痼疾。
把责任推给学校显然无济于事。不论你是学生还是职业软件工程师，如果你不懂需求工程，你就不可能把产品做好。为了你的前途，你应该认真学习需求工程。
令人遗憾的是大多数软件工程教科书喜欢以学术的形式论述需求，大讲结构化分析或面向对象分析，并给出一堆模型和符号。然而大部分开发人员首先要学习的是如何调查需求、如何写需求文档等基本技能。需求工程是经典软件工程的核心内容，按理说早就研究得相当透彻了，奇怪的是人们就是学不好、用不好。可见需求工程的研究者似乎并不清楚实践者的真正需求，真让人哭笑不得。
有个射击教练教出了不少神枪手，那些神枪手的枪法虽然很准，但老是打错人，有的甚至拿枪来自杀。你能说射击教练教和神枪手们合格吗？
基于我自己学习以及培训别人的心得体会，我准备以说理的方式论述需求工程，期望能减轻软件开发人员心头长久的痛。
4.1 什么是需求
4.1.1 基本概念
宽泛地讲，需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。
所以如果只有一些零碎的对话、资料或邮件，你就以为自己已经掌握了需求，那是自欺欺人。
人们常问：“需求、设计、编程、测试四者究竟哪个重要？”
这个问题不好回答。四者都是软件开发过程中必不可少的环节，光做好其中一个环节并不能产生好的系统，但是做坏了其中任何一个环节，必定对系统产生坏影响。若站在风险管理角度讲，我认为需求开发与管理是最重要的环节。因为需求是产品的根源，需求工作的优劣对产品影响最大。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。
Frederick Brooks在他1987年的经典文章“No Silver Bullet”中阐述了需求的重要性：开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。
没有软件工程书籍不强调需求的重要性，也几乎没有软件开发人员不知道需求的重要性。但是读过书并不表示就能够熟练掌握，需求工作说起来容易做起来难啊。
根据我的观察和切身体会，大部分软件开发人员并不知道如何把需求工作做好。在我为本公司软件开发人员写需求工程培训教材时，恰好遇到公司里一群高智商的开发人员集体犯需求观念错误的事情。我就把它写成案例，现炒现卖。
4.1.2 需求案例
本公司是国内一家大型的电信设备供应商，本案例涉及6个机构A,B,C,D,E和F，它们之间的关系如图4-1所示。故事是这样的：
A和B都是公司的研发机构，B做核心平台的研发，A做增值业务的研发（我在A工作）。C是公司的项目管理机构，负责立项、结项和研发经费管理。D是公司的一个销售机构。
一年前，B研制了一种数据接入服务器的原型。B对A讲：“我们的接入服务器前途很好，请你们帮助开发网管软件（属于增值业务范畴），大家合作把产品做好，一起发财。”
D对B和A讲：“你们把接入服务器和网管软件做好，我们负责卖，挣了钱大家一起分。”
A想了想觉得机会难得，于是向C申请立项。立项后，A把该项目外包给一家专业做网管软件的公司E，期望半年内完成。由于接入服务器是B的，于是A和E就派开发人
员到B处搞需求分析。B的接入服务器并不成熟，老在变，三方折腾了好久，最终E用了一年时间把接入服务器的网管软件做出来了。
E把网管软件交付给A，A付清了E的开发费用，再把网管软件交付给D，D再卖给客户F（某地电信局）。F对D讲：“你们的网管软件不是我们想要的东西，等你们把软件改好后我们再付钱。”
D赶紧对A讲：“兄弟阿，货已经出手了，但是不对路，请赶紧把它改好，不然大家都没钱赚。”
A很愤怒，怨天不公：“我们辛苦了一年，又花了很多钱，可是产品做完了却没人要，岂有此理！”
祸不单行的是，C来找A的麻烦：“你们的项目延期半年多了，经费也用光了，请尽快结束项目。”
A的那位项目经理为此每天愁眉苦脸，他的上司请来几位参谋商量对策（包括我在内），设法把事情搞定。大家挖空心思只想出一个馊主意：既然套子是B下的，那么就把套子还给B。要设法把“那么好”的网管产品转让给B，只要B能给我们成本费，以后就跟B拜拜。
图4-1 本案例6个机构的关系图
读者听了这个故事肯定既迷糊又惊诧：“哇，大公司是这样开发产品的啊？”。我也是在人家请我商量对策的时候，才知道有这样的事情。
问题的根源在于没有搞清楚网管软件的需求，这都是B,A,E闭门造车惹的祸。三方开发团队里可是有不少的博士、硕士呐，可是他们集体犯了如此低级的错误。最可悲的是，相关责任人关心的是如何把事情“搞定”，而不是深刻反思。估计类似的事情还会继续发生，每发生一次就损失成百上千万元。大公司再有钱也会给浪费光的。
讲了这个故事，我不免有所感叹：需求问题有时如同爱情问题，真是“当局者迷，旁观者清”啊。我自己也是这么过来的，但愿以后不再犯类似的错误。
4.2 了解用户
“用户”（user）是一种泛称，它可细分为“客户”（customer）、“最终用户”（the end user）和“间接用户”（或称为关系人）。
掏钱买软件的用户称为客户，而真正操作软件的用户叫最终用户。客户与最终用户可能是同一个人也可能不是同一个人。如果软件是面向企业用户的，那么客户与最终用户通常不是同一个人。如果软件是面向个人用户的，那么客户与最终用户通常是同一个人。
由于客户是掏钱买软件的人，所以他是“上帝”。“现代营销学之父”菲利普?科特勒所著的《市场营销导论》是这样描述客户的：
客户永远是本公司的座上客。客户并不依赖我们，而我们却依赖客户。客户不是我们工作的障碍，而是我们工作的目标。我们并不因为服务于他而对他有恩，他却因为给予我们服务于他的机会而有恩于我们。客户不是我们要与之争辩和斗智的人。从未有人曾在与客户的争辩中获胜。客户是把他的欲望带给我们的人，因此我们的工作就是满足这些欲望，从而使客户和我们共同获益。[科特勒2001, p25]
某饭店经理在解释“先有鸡还是先有蛋”这个哲学问题时，精辟地阐述了客户的地位：如果顾客先点鸡，那么就先有鸡；如果顾客先点蛋，那么就先有蛋。
软件开发方与客户打交道的主要目的是：一是获取需求，二是签合同。客户所说的需求一般比较宏观，更详细的需求应该从最终用户那里获取。对于大宗买卖，软件开发方会把“上帝”侍侯得舒舒服服，想方设法拿到合同。利益往往诱使人们搞不正之风，洽谈业务时少不了吃喝玩乐。我有位在国内大型电信企业搞销售的朋友，几乎每周都出差，带一帮客户老爷们游山玩水。这种做法差不多成了电信行业的“事实标准”。羊毛出在羊身上，奢侈花费最终将摊到老百姓的头上。为了避免被客户怀疑是在挖墙角，国内电信厂商一般不会招聘从电信局辞职的人，足见厂商对客户的“敬重”。
有不少客户精通业务，技术水平相当不错。跟这些客户打交道，开发方千万别派出只会吹牛皮的“酒囊饭袋”之辈。我曾听说有些项目负责人在竞标时，在技术方面竟然被客户反驳得哑口无言，着实丢脸。
如果项目规模比较大，那么开发方与最终用户的来往就比较多。如从最终用户那里获取详细的需求，请最终用户试验软件，对最终用户进行培训等等。即使最终用户不是上帝，也算是“上帝”的“亲戚”，同样怠慢不得。有一次我们公司新员工上产品培训课，有位小领导匆匆赶来作指示：“隔壁班正在给电信局的员工们进行培训，他们都是上帝派来的，大家要注意形象。由于休息室空间有限，请大家自觉让位。午休时他们可以躺着睡，我们只能坐在位置上打个盹儿…….。”
除了客户和最终用户之外，软件开发方不能疏忽另一类用户——“间接用户”，千万别“大意失荆州”啊。
间接用户既不掏钱买该软件产品，也不使用该软件，但是它可能对软件产品有很大的影响。例如，财务软件开发商在把“财务软件”卖给客户之前，这个“财务软件”必须得到国家财政部的批准。否则即使该软件的功能是完美的，但却被政府认为是非法的。所以国家财政部就是所有财务软件的间接用户，它不仅不付钱给财务软件开发商，反而
要收取鉴定费、手续费等。同理，市面上流通的信息安全软件、杀病毒软件必须得到国家公安部的批准，否则软件开发商被逮住后戴上“非法经营”的帽子就惨了。
4.3 需求工程
4.3.1 基本概念
我们把所有与需求直接相关的活动通称为需求工程。需求工程中的活动可分为两大类，一类属于需求开发，另一类属于需求管理。需求工程的结构如图4-2所示，需求开发与需求管理的流程如图4-3所示。
图4-2 需求工程结构图
需求开发的目的是通过调查与分析，获取用户需求并定义产品需求。需求开发过程域有3个主要活动：
?需求调查。需求调查的目的是通过各种途径获取用户的需求信息（原始材料），
产生《用户需求说明书》。
?需求分析。需求分析的目的是对各种需求信息进行分析，消除错误，刻画细节
等。常见的需求分析方法有“问答分析法”和“建模分析法”两类。
?需求定义。需求定义的目的是根据需求调查和需求分析的结果，进一步定义准
确无误的产品需求，产生《产品需求规格说明书》。系统设计人员将依据《产品
需求规格说明书》开展系统设计工作。
需求开发过程域可分为两个阶段：“用户需求调查阶段”和“产品需求定义阶段”。两者在逻辑上存在先后关系，实际工作中二者通常是迭代进行的。我们把从事需求开发工作的人员称为需求分析员（也叫系统分析员），避免与其它开发人员混淆。“需求分析”活动贯穿于“用户需求调查”和“产品需求定义”两个阶段。
需求开发过程域产生的主要文档有：
?《用户需求说明书》
?《产品需求规格说明书》（对于软件产品而言就是《软件需求规格说明书》）
需求管理的目的是在客户与开发方之间建立对需求的共同理解，维护需求与其它工作成果的一致性，并控制需求的变更。需求管理过程域有3个主要活动：
?需求确认。需求确认是指开发方和客户共同对需求文档进行评审，双方对需求
达成共识后作出书面承诺，使需求文档具有商业合同效果。
?需求跟踪。需求跟踪是指通过比较需求文档与后续工作成果之间的对应关系，
建立与维护“需求跟踪矩阵”，确保产品依据需求文档进行开发。
?需求变更控制。需求变更控制是指依据“变更申请－审批－更改－重新确认”
的流程处理需求的变更，防止需求变更失去控制而导致项目发生混乱。
需求管理过程域产生的主要文档有：
?《需求评审报告》
?《需求跟踪报告》
?《需求变更控制报告》
图4-3 需求开发与需求管理流程图
4.3.2 一些感悟
本章通篇都在讲解需求工程的方法与技术，但是我担心读者辛苦地学习了，却可能在实践时用歪了。因此我要先谈谈自己对需求工程的一些感悟。
需求工程感悟之一：不论是合同项目还是自主研发的产品，都必须开展需求开发和需求管理活动。
对于合同项目，由于客户是已知的，需求开发和需求管理的各项活动可以有的放矢
地开展。但是对于自主研发的产品而言，在产品没有卖出之前，并不存在真正的用户。由于用户是未知的，这就产生了令人困惑的问题：究竟该向谁调查需求？由谁来确认需求？
很多开发人员不知不觉落入陷阱：既然产品是自主研发的，反正目前没有用户，那么就让我们自己设想需求、自己确认需求吧！
此念一起，祸根埋下。如此开发的产品十有八九会落得前述案例的下场。相似惨痛的教训实在太多，人们一定要清醒啊。
即便待开发的产品尚未有真正的用户，但必定有潜在的用户（如果连潜在的用户都没有，那么就不要开发这样的产品，否则开发出来卖给谁？）。开发人员可以向潜在的用户们调查需求，请他们来确认需求。如果因条件限制，实在请不到潜在的用户，那么开发者可以把自己一分为二，既当用户又当分析员。注意在扮演用户这个角色时，应当忘记自己是开发者，一定要真正地站在用户的立场思考问题。一旦混淆角色，就会犯错误。
需求工程感悟之二：开发者对待需求工程的态度可分“被动型”、“主动型”和“领先型”三种，只有后两种才有可能开发出成功的产品。
“被动型”是指开发者被动地对待需求工程中的各项活动，能少干则少干，能偷懒则偷懒。他们认为需求是用户的事情而不是自己的事情。开发过程中经常发生需求变更，导致产品迷失方向，不是半途而废就是陷入半死不活的状态。
“主动型”是指开发者积极地开展需求工程中的各项活动。他们把获取准确的需求当作自己的职责，会想尽一切办法克服需求开发和需求管理过程中的困难，而不是找借口推卸责任。俗话说“良好的开端是成功的一半”，“主动型”需求工程是开发成功产品的必备条件。
“领先型”是需求工程的最高境界。开发者发掘了连用户自己都没有意识到的需求，导致用户跟着新产品跑而不是新产品围着用户转，这叫引导消费。需求工程做到这个份上，才能使产品立于不败之地，长盛不衰。
4.4 需求开发的主要困难与对策
4.4.1 知识技能问题
绝大多数软件开发人员在学生时期的学习重点是计算机技术，他们毕业后到企业工作，主要任务依然是技术开发。由于专业和职业的原因，多数软件开发人员不擅长与用户交流。有些人技术很出色，但与用户在一起时显得很木讷，有劲使不出。所以企业不能期望他们能够无师自通地把需求开发工作做好。最好最快的解决办法是培训。如果你是项目的领导，既然你要把那么重要的工作（需求开发）交给他们去做，你就要舍得花钱对他们进行需求开发培训，帮助他们把需求开发工作做好。
即使需求分析员对需求调查、需求分析、需求定义已经有了丰富的经验，但他们的知识仍然可能不够用。应用域的知识是无边无际的，任何人都不可能是“万事通”。俗话说“隔行如隔山”，需求分析员可能是某一领域的专家，但当他接手陌生的业务时，他可
能是个“无知”者。一个企业要谋求发展，不能总在做老的业务。人一生中会有许多充满挫折的“第一次”，不可以逃避。
当需求分析员缺乏应用域知识时，他该怎么办？
首先他要有勇气做事，否则连实践的机会都没有。其次他应当赶紧补习应用域知识，不论是通过自学还是培训的方式，否则他很难与用户交流。如果可能的话，开发方最好请既懂软件又懂应用域知识的行家来帮忙。
如果需求分析员完全不了解应用域，而用户几乎是个计算机盲，并且双方都不愿意主动了解对方领域的事情，这种状况下的需求开发很难成功。
这世上没有人能够在知识面前耍花招，“不懂装懂，永远饭桶”。
4.4.2 态度问题
相当多的开发人员习惯于被动地对待需求开发。每当遇到麻烦、挫折时，他们会发牢骚，找出一堆用户的毛病。这是普遍现象，并不是开发人员懒惰所造成的，而是不正确的观念误导了他们！
很多开发人员错误地以为：需求是用户的事情，不是我们的事情。我们为用户开发软件，难道用户不该告诉我们应当开发什么吗？如果用户说不清楚需求，或者经常变更需求，这类问题是用户产生的，应当由他们自己负责。
用户说不清楚需求或者需求发生变更，这些都是常见的问题，并不是绝症，是人们可以设法解决的。可悲的是开发人员把这些问题当成了借口，不愿主动攻克问题，导致需求问题扩散到整个软件开发过程，产生太多的后患。
软件企业的领导应当给具有错误观念的开发人员们洗脑：需求分析员的天职就是在有限的时间内获取准确而细致的用户需求，如果做不到就是失职，不要找借口。
4.4.3 合作关系
如果需求分析员不能与用户建立良好的合作关系，那么他们在需求开发过程中会很疲惫。
倘若用户不能很好地配合需求分析员，那并不表示他是个坏蛋。因为用户有他自己的想法：
我回答了你们的问题，讲了该讲的。我们付钱给你们，难道还要我伺候你们不成？我还要干自己的事情，别打扰我了。你们自己想办法把活干好吧……。
对于一些竞标项目，在合同未签订之前的需求开发工作尤为困难。用户未必会买你的产品，他不会投入很多精力来协助你搞需求开发。
我是个软件开发人员，有时我又成为别的软件公司的用户，需求开发过程中的两类角色我都经历过，很有感受。举一例谈谈。
公司曾有一个关于企业管理的项目要外包，项目金额不小，有数家软件公司来竞标。他们在做方案时，我是被访问的主要“用户”之一。我虽然是个用户，但真的不清楚这
个项目的需求，说不出长篇大论，只能人家问什么我回答什么。由于我有重要的研发、管理工作要做（每个人都会觉得自己的工作很重要），不愿意老被别人的访问打扰，有时想回避。然而将心比心（或者说同病相怜吧），我也是开发人员，知道吃这碗饭不容易，我理应帮他们一把。
我想了一个办法：请我的几位小组成员轮流代我参加需求调查会议。我提醒组员：“我们要热情地为调查者解答疑问，同时要观察、体会他们的调查方法，学习好的、屏弃差的。因为我们以后也要向别人调查需求。”
需求分析员不是销售人员，他们不可能象销售人员那样通过某些手段笼络住用户就能成功。出色的需求分析员不仅要有过硬的专业知识，还要具备较强的交流、沟通能力，否则会把事情搞砸的。在上例中，有些调查人员和我谈方案时，结果我发现他们的水平还不及我们小组的高，真不知道是谁给谁做方案。把他们一送出大门，我就打了“小报告”，他们的机会变得很渺茫。有些调查人员为了讨好我，不停地说好话、套近乎。说好话当然让我高兴，但是听多了，让我感觉此人很圆滑，反而印象不好，于是应付了事。有些调查人员倒是很务实，一上来就问问题、填写调查报告，一点好话都不会说，让我提不起兴趣，我也不想多谈。
有些感受挺有趣，每当我认真思考这些事情时，不禁心事重重。有太多的开发人员不懂得“如何做好”需求开发，这并不有趣，组建优秀的开发团队谈何容易啊！
开发方与用户的合作关系对需求开发而言是至关重要的。对于重大的、复杂的项目，我们不能完全期望双方能够自发地建立起良好地合作关系，这样风险太大。文献[Wiegers2000, p12-p16] 给出了一种好方法：开发方和用户方在开展需求开发之前，双方协商并撰写“用户在需求工程中的权利与义务”，即以协议的方式确定合作关系。“好话”和“丑话”都说在前头，这样能减少今后的摩擦。如果条件允许的话，开发方最好为用户举办关于需求工程的培训，这样的培训将使用户明白需求的重要性以及忽视需求的危害性，从而促使他们积极友善地参加需求工程中的各项活动。
表4-1列举了用户在需求工程中的“权利与义务”，读者可以根据实际情况适当地修改。
表4-1用户在需求工程中的“权利与义务”
4.4.4 用户说不清楚需求
用户说不清楚需求是普遍现象，这是让开发人员头痛的大问题。
有些用户真的不知道需求是什么，或者对需求只有朦胧的感觉，他当然说不清楚需求。开发人员可能觉得奇怪：用户自己都不知道要什么，为什么还要我们开发软件？
这种现象有些时候是正常的，例如开发方的营销人员水平比较高，他能够在用户不清楚自己要什么的情况下引导用户“消费”。也有不正常的现象，例如前些年全国各地的很多政府机构大搞网络建设。这些机构的领导和办公人员大多数不清楚网络干什么用，就让开发人员替他们设想需求吧，反正是花公家的钱。
有些用户虽然心里明白想要什么，但却说不清楚需求。读者可能很不以为然，用户不致于笨到这个地步吧？
这不是聪明或笨的问题，是表达能力问题。举个日常生活的事例，比如说买鞋子。我们非常了解自已的脚，但很难用语言说清楚脚的大小和形状。通常拿鞋子去试，试穿时感觉到舒服才会买鞋（居然也有神通广大的售货员，看一眼用户的手，就知道应该穿什么样的鞋）。真所谓“道可道，非常道。明可明，非常明。”
需求分析员绝不能以用户说不清楚需求为借口而草率地对待需求开发工作，否则会连累整个开发团队的。无论是什么原因导致用户说不清楚需求，需求分析员必须设法搞清楚用户真正的需求，这是需求分析员的职责，也是职业的挑战。
4.4.5 双方误解需求
人们在交流的时候，经常会发生“问非所求，答非所问”的事情。
有时用户会把开发人员的建议或答复给想歪了：
有一个软件开发人员滔滔不绝地向用户讲解在?信息高速公路上做广告?的种种好处，用户听得津津有味。最后，心动的用户对软件开发人员说：?好得很，就让我们马上行动起来吧。请您决定广告牌的尺寸和放在哪条高速公路上，我立即派人去做。?而用户表达的需求，不同的开发人员可能有不同的理解。如果需求分析员误解了需求，那会导致后续的不少开发人员将错就错、白干活。就像作文写跑题了，写得再好也白搭。这类错误连高智商的外星人都不能避免：
有个外星人间谍潜伏到地球刺探情报，它给上司写了一份报告：?主宰地球的是车。它们喝汽油，靠四个轮子滚动前进。嗓门极大，在夜里双眼能射出强光。……有趣的是，车里住着一种叫作‘人’的寄生虫，这些寄生虫完全控制了车。?
不论是复杂的项目还是简单的项目，需求分析员和用户都有可能误解需求。所以需求确认工作（属于需求管理）必不可少。
4.4.6 开发人员写不好需求文档
开发人员写不好需求文档的主要原因如下：
●需求调查工作不充分，获取的需求信息太少或者太乱，以至于写不成需求文档。古
时候，一书生在考试前补习“写文章”，成天愁眉苦脸。其夫人甚为不解，问：“相公，你写文章比我生小孩还难吗？”书生长叹一声：“娘子你哪里知道我的难处啊！
你生小孩时肚子里有东西，可我写文章时肚子里没东西啊。”所以要想写出好的需求文档，前提条件是把需求调查工作做好。
●开发人员写作能力比较差，虽然在调查过程中已经获得了不少需求信息，却写不出
好的需求文档来。我可以毫不夸张地说，国内90％以上的软件开发人员，他们的写作能力远不及开发能力。提高开发人员写作能力的根本办法就是让他们多练习写文档，熟能生巧嘛。另外，企业应当提供合适的文档模板以及比较好的示例文档，尽可能地降低写作难度。
4.4.7 用户经常变更需求
需求变更通常会对项目的进度、人力资源、经费产生很大的影响，这是开发商非常畏惧的问题。
如果在项目开发的初始阶段，开发人员和用户没有搞清楚需求或者搞错了需求，到了项目开发后期才将需求纠正过来，导致产品的部分内容需要重新开发。毫无疑问，这种需求变更将使项目付出额外的代价。这种损失是由于双方工作失误造成的，双方应当好好反省，认真学习需求开发和管理的方法，避免再犯相似的错误。
如果由于市场变化而导致产品需求发生变更，开发商大可不必为此烦恼，应当高兴才对。倘若市场静如死水，那么开发商吃了“上一顿”就没有“下一顿”。正因为市场在变化，才会产生更多商机，聪明的开发商才会有活干，有钱赚。
其实需求变更并不可怕，可怕的是需求变更失去控制，导致项目混乱。所以需求变更控制是需求工程的重要活动，详见本章第11节的论述。
4.5 如何开展需求调查
4.5.1 需求调查规程
开展需求调查不能学情人之间的浪漫做法——“让我摸摸你的头发，感觉它是什么颜色。”
需求调查的一般规程如表4-2所示。
表4-2 需求调查的规程
4.5.2 准备调查
需求调查准备工作围绕三项展开：（1）调查什么？（2）通过什么方式去调查？（3）“何人”在“何时”调查？
●首先，需求分析员应当起草需求调查问题表，将调查重点锁定在该问题表内，否则
调查工作将变得漫无边际。问题表可以有多份，随着调查的深入，问题表将不断地被细化。根据经验，用户通常没有耐心回答复杂的“论述题”，所以问题表应当以“选择题”和“是非题”为主。制定问题表最简便的方法就是从《用户需求说明书》的模板中提取需求问题。
●其次，需求分析员应当确定需求调查的方式，例如：
?与用户交谈，向用户提问题。
?参观用户的工作流程，观察用户的操作。
?向用户群体发调查问卷。
?与同行、专家交谈，听取他们的意见。
?分析已经存在的同类软件产品，提取需求。
?从行业标准、规则中提取需求。
?从Internet上搜查相关资料。
●最后，需求分析员与被调查者建立联系，确定调查的时间、地点、人员等，撰写需
求调查计划。要特别留意的是不要漏掉典型的用户。
4.5.3 调查与记录
准备工作完毕后，需求分析员按照计划执行调查。在调查过程中随时记录（或存储）需求信息，建议采用表格的形式，如表4-3所示。
表4-3 需求信息表格示例
需求分析员与用户面谈时应当注意以下事项：
?如果与用户约好了时间，切勿迟到或早退。要注意礼节，尽可能获得用户的好
感，并为下次打扰他们埋下伏笔。
?需求分析员应事先了解用户的身份、背景，以便随机应变。IT人士不可貌相，
有些大企业的领导其外表很土气，象农民。如果你路上碰到他，以为是个勤杂
工，说：“喂，老师傅，来帮我拎东西。”也许这笔生意就泡汤了。
?需求调查不象侦探推理那样从蛛丝马迹着手，应该先了解宏观问题，再了解细
节问题。
?如果双方气氛融洽，可以采用灵活的访谈形式，轻易不要打断用户的谈话。当
双方对某些问题的交流合乎逻辑地结束后，即可继续讨论问题表中的其它问题。
?尽可能避免为用户添麻烦，但也不能怕给用户添麻烦而降低需求调查的力度。
?避免片面地听取某些用户的需求而忽视其它用户的需求。
如果有些事情现场就能分析清楚，那么不要拖延到以后做。在调查需求的同时应当进行必要的需求分析，建议采用“问答分析法”（详见 4.6.1节），尽可能确定每个需求的基本要素，如“是什么”、“为什么”等。
4.5.4 撰写用户需求说明书
需求分析员对收集到的所有需求信息进行分析（方法详见4.6节），消除错误，归纳与总结共性的用户需求。然后按照指定的文档模板（见表4-3）撰写《用户需求说明书》，调查过程中获取的需求信息（见表4-2）可以作为《用户需求说明书》的附件。
《用户需求说明书》撰写完毕之后，需求分析员应当邀请同行专家和用户（包括客户和最终用户）一起评审《用户需求说明书》，尽最大努力使《用户需求说明书》能够正确无误地反映用户的真实意愿。之后才进一步定义产品的需求，产生《产品需求规格说明书》。
《用户需求说明书》与《产品需求规格说明书》的主要区别与联系是：
（1）前者主要采用自然语言（和应用域术语）来表达用户需求，其内容相对于后者而言比较粗略，不够详细。
（2）后者是前者的细化，更多地采用计算机语言和图形符号来刻画需求，产品需求是软
件系统设计的直接依据。
（3）两者之间可能并不存在一一影射关系，因为软件开发商会根据产品发展战略、企业当前状况适当地调整产品需求，例如用户需求可能被分配到软件的数个版本中。软件开发人员应当依据《产品需求规格说明书》来开发当前产品。
《用户需求说明书》的参考模板见表4-4。
表4-4 《用户需求说明书》的参考模板
4.6 如何进行需求分析
为了得到用户的金钱，企业不得不鼓吹：用户就是上帝，用户永远是正确的。
谁都知道这不是真的。事实上，很多时候用户说不清楚需求、会说错需求或者提出一些无法实现的需求。
需求分析是指在需求开发过程中，对所获取的需求信息进行分析，及时排除错误和弥补不足，确保需求文档正确地反映用户的真实意图。
需求分析是需求开发过程中最费脑子的工作。分析方法大体有两类：“问答分析法”和“建模分析法”。后者技术性比较强，写出来有学术味，故大多数软件工程书籍都有论述。前者就是一些常识而已，虽然写不成文章，但是简单易用（保你一学就会），很有实用价值。
根据作者的经验，“问答分析法”比较适合于用户需求调查阶段，而“建模分析法”比较适合于产品需求定义阶段。
4.6.1 问答分析法
问答分析方法很简单：刨根究底地问，如果问题都被解答了，那么需求也就分析清楚了。一个人可以“自问自答”地分析需求，几个人分析需求则称为“研讨”。
问答分析最重要的问题是：“是什么”和“为什么”。
每个需求都应当用陈述句说明“是什么”，如果“是什么”的内涵不够清晰，则应补充说明“不是什么”。如果“是什么”和“不是什么”并不是“理所当然”的，那么应当解释“为什么”，以便加深读者的理解。追究“是什么”和“为什么”的目的是获得正确、清楚的需求。
其它常见的问题有：
?需求存在二义性吗？
?需求文档的上下文有矛盾吗？
?需求完备吗？
?需求是必要的吗？
?需求可实现吗？
?需求可验证吗？
?需求的优先级确定了吗？
4.6.2 建模分析法
人们都有这样地感受：有些时候用语言描述某个问题特别费劲，而采用图形则使人
一目了然，所谓“一图低千言”就是这个道理。
在需求开发过程中，对于某些类型的信息，用图形表示要比文本表示更加有效。所以将图形与文本结合起来描述需求是很自然的方法。需求建模就是指用图形符号来表示、刻画需求。建模分析方法主要有两大类：“结构化分析法”和“面向对象分析法”。
4.6.2.1 结构化分析法
软件的建模分析兴起于20世纪60年代末期和70年代初期。结构化分析方法并不是由里程碑式的明确地涉及这个主题的一篇文章或者一本著作引入的，它也不是被所有使用者一致采用的单一方法。相反地，它是几乎发展了20多年的一个混合物。结构化分析方法在70年代和80年代非常流行，相关论著很多。对结构化分析方法有较大贡献的学者有DeMarco, Gane, Sarsen, Yourdon, Constantine, Ward, Mellor, Hatly, Pirbhai等人。文献[Pressmen99, p206-p214]对结构化分析方法作了高度概括（如图4-4所示），我们不妨称之为“一个中心三种图”：
?“数据字典”是中心，它包含了软件中所有数据对象的描述。
?“实体－关系图”是用图形符号来标识数据对象以及它们之间的关系。
?“数据流图”指明了数据在系统中移动时如何被变换。
?“状态－变迁图”表示了系统存在的各种状态以及它们之间的变迁方式。
图4-4 结构化分析方法示意图
4.6.2.2 面向对象分析法
面向对象分析设计（OOAD）方法兴起于20世纪80年代，从90年代起至今它已经在分析设计领域占据了无可争议的主流地位。
我在读本科（90年至94年）时就充分地感受到了人们对“面向对象”的狂热。关于“面向对象”的课堂、学术报告常常人满为患。搞软件研发的人都“言必谈对象”，并引以为荣。
面向对象分析设计领域有一些比较著名的学派，如：
?Coad和Yourdon学派，其代表作为[Coad91]。
?Booch学派，其代表作为[Booch94]。
?Jocobson学派，其代表作为[Jacobson92]。
?Rumbaugh学派，其代表作为[Rumbaugh91]。
有趣的是，这些学派的掌门人就像上帝、真主、如来佛，他们用各自的方式定义了这个世界，并留下一堆经书来解释这个世界。这种混乱的局面被学术界称为百家争鸣，每年诞生了许多论著和教授。叫苦的是软件企业和开发人员：没有统一的方法，不好干活啊！
终于等到了那一天，Rational公司招纳了Booch, Jocobson, Rumbaugh，这三位“面向对象”业界的老大强强联手，制定了“统一建模语言”（UML）。1997年11月，UML 被国际对象管理组织（OMG）采纳，此后UML成为OOAD建模语言的国际标准。
UML吸取了各种OOAD方法的精髓，对于OOAD中的语义、图形表示法和使用规则作了完整而详细的定义。UML的建模能力超过了以往任何一种OOAD方法，当然其复杂性也随之膨胀。大多数软件开发人员没有兴趣阅读枯燥乏味的UML文档（如[Rumbaugh99]）。真正使UML流行的是Rational公司基于UML的建模工具Rose。Rose 易学易用，它能交互式地构建类图、用例图、构件图、部署图、状态图、活动图、顺序图、协作图等等，深得开发人员的喜爱。
介绍UML和Rose的书籍非常多，读者自己选择、学习，这里不再论述。
4.6.2.3 恰当地使用图形符号
现代建模工具如Rose有非常丰富的图形符号和文字标注，能很好地表达模型的细节。要注意的是：在建模时使用花样过多的图形符号或文字意味着模型表示的复杂化，将使开发人员更难掌握，而且使图形文档更加杂乱。
世上不存在一个包罗万象的图——它能完整地描述需求。需求建模不可能取代文字描述。在需求文档中，文字描述是第一重要的，建模主要是起分析、解释作用。建议将模型存放在需求文档的附录中，便于正文引用。
4.6.3 作出决策
当需求从四面八方收集来后，需求的冲突在所难免。对于那些难以达成共识的需求而言，经常会发生“公说公有理，婆说婆有理”的现象。那么需求分析员究竟应该听谁的呢？
这个问题没有标准答案。以下是一些经验之谈：
●如果一群人对需求有争议，并不是谁声音最响就听谁的。根据生活经验，最保险的
办法是：先听官儿大的或者威望高的，如果大家的职位和威望都差不多，那么采用“少数服从大多数”的原则。这样做的好处是当出了差错时，需求分析员就有理由为自己辩护，从而保护自身利益。读者不要觉得这种“明哲保身”的做法很低俗：“身为软件研发人员，怎么可以不坚持真理呢？”唉，需求本来就不是真理，它来源于人们的欲望。大家值得为不是真理的需求争得不可开交吗？
●如果一个产品可以卖给几类客户，但是各类客户都要求产品按照他们的喜好来开发。
此时对需求的决策应当以商业利益为导向，即哪一类客户出钱最多就先满足他们的需求，以后再做那些获利相对较少的需求。
当开发者想象中的产品与客户所提的需求有冲突时，一般应当尊重客户的观点。但是不要陷入“客户总是对的”陷阱里，需求分析员应当纠正明显不合理的客户需求。
如果产品很复杂，双方都不太明白需求，此时最好请开发人员快速构造软件的原型，双方看着软件原型再分析需求。
4.7 什么是好的产品需求规格说明书
好的产品需求规格说明书有如下属性：正确、清楚、无二义性、一致、必要、完备、可实现、可验证。
4.7.1 正确
需求规格说明书应当正确地反映用户的真实意图，“正确”是《产品需求规格说明书》最重要的属性。如果“不正确”仅仅是由于错别字造成的，那么多检查几遍文档就能解决问题。真正的困难是开发者和用户自己都不明白用户究竟“想要什么”和“不要什么”。为确保需求是正确的，开发方和用户必须对《需求规格说明书》进行确认。
4.7.2 清楚
电影《新少林五祖》里有一段精彩的需求对话。绰号叫“日行一善”的财主想请武艺高强的洪熙官（李连杰演）做他的保镖，他提出的需求只有四句话：（1）如果有人欺负我，你帮我打他。
（2）如果有人抢我的东西，你帮我打他。
（3）如果我欺负别人，你帮我打他。
（4）如果我抢别人的东西，你帮我打他。
清楚（Clarity）的需求让人易读易懂，上例就是榜样。清楚的反义词是“难读”、“难理解”。你可以采用反问的方式来判断需求文档是否清楚：
（1）文档的结构、段落是否乱七八糟？上下文是否不连贯？
（2）文档的语句是否含糊其词、罗里罗嗦？
（3）看了半天是否还不明白需求究竟是什么？
4.7.3 无二义性
“无二义性”（Unambiguous）是指每个需求只有唯一的含义。如果一个人说的话，不同的人可能有不同的理解，那么这句话就有二义性。如果需求存在二义性，将会导致人们误解需求而开发出偏离需求的产品。
80年代中国老百姓致富的口号是“奔小康”，这个口号听起来“正确”并且“清楚”，但不能当成政策来推行。人们对“小康”的理解不尽相同，所以“小康”这词存在二义
CMM中的需求管理与需求开发
需求管理（Requirements Management ）是属于CMM2中的过程域，简 称为REQM ，需求开发（Requirements Development ）是CMM3中的过程域，简称RD 。这两个过程域是CMMI 体系中关于需求的全部内容，下面分别对这两部分进行介绍。本文对CMM 的一些基础知识、基础术语不再介绍。 需求管理与需求开发的分界线： 市场营销 用户需求 管理层 需求开发 需求管理 市场 营销 管理层需求变更项目环境 项目变更 大家可以这样理解，需求管理是指对需求变更的管理、对需求的跟踪，而获取需求、定义需求则属于需求开发部分。 需求管理 在CMMI 中，需求管理的目标定义为： a. 把软件需求建立一个基线供软件工程和管理使用。 b. 软件计划、活动和工作产品同软件需求保持一致。 更高的目标： 软件需求的复用
需求管理的原则和方法 a. 必须与需求工程的其他活动紧密整合
b. 需求必须是文档化的、正确的、最新的、可管理的、可理解的 c. 只要需求变化了，需求变更的影响就必须被评估 d. 需求必须分优先级 e. 需求一定要分类管理 需求管理的主要工作： 特定目标和特定实践 特定目标 ●管理需求 管理需求并识别需求与项目计划和工作产品之间的差 异。 ●SP 1.1 取得需求理解 ●SP 1.2 取得需求承诺 ●SP 1.3 管理需求变更 ●SP 1.4 维护需求的双向追溯性 ●SP 1.5 识别项目工作与需求间的差异 REQM特定目标的关系
SP 1.1 取得需求理解 SP 1.1 和需求提出者一同来了解需求。 l 识别出谁是需求的提供者 l 识别出需求的接受标准： a. Clearly and properly stated得到清晰和恰当的定义 b. Complete完整的 c. Consistent with each other相互一致的 d. Uniquely identified得到唯一标识的 e. Appropriate to implement适宜实现 f. Verifiable (testable)可以验证（测试） g. Traceable可追溯 l 分析需求，确保符合已建立的准则。 l 与需求提供者达到需求共识，以使项目成员能承诺它们SP1.2 获取对需求的承诺 SP1.2 取得项目成员对需求的承诺。 ●评估需求对现有承诺的影响。 需求变更或新需求发生时，评估它们对项目成员的影 响。 ●协商并记录承诺。
软件需求开发与管理
软件需求开发与管理 1概述 需求是从系统外部能发现系统所具有的满足于用户的特点、功能及属性等。需求是指明必须实现什么的规格说明。它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。 软件需求工程划分为需求开发和需求管理，其中需求开发可进一步分为问题获取(elicitation)、分析(analysis)、编写规格说明(specification)和验证(verification)四个阶段, 需求开发活动包括以下几个方面： (1)确定产品所期望的用户类 (2)获取每个用户类的需求 (3)了解实际用户任务和目标以及这些任务所支持的业务需求 (4)分析源于用户的信息以区别用户任务需求、功能需求、业务规则、质量属性、建议解决 方法和附加信息 (5)将系统级的需求分为几个子系统，并将需求中的一部分分配给软件组件 (6)了解相关质量属性的重要性 (7)商讨实施优先级的划分 (8)将所发现的用户需求编写成规格说明和用例模型 (9)评审用例和需求规格说明，确保对用户需求达到共同的理解与认识，并在整个开发小组 接受说明之前将问题都弄清楚。 需求管理活动包括以下几个方面： (1)定义需求基线(迅速制定需求文档的主体) (2)评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它 (3)以一种可控制的方式将需求变更融入到项目中 (4)使当前的项目计划与需求一致 (5)估计变更需求所产生的影响并在此基础上协商新的承诺。 (6)让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪 (7)在整个项目过程中跟踪需求状态及其变更情况。 2需求工程的推荐方法 需求工程推荐方法 需求开发
产品需求分析管理和产品规划培训课程
产品需求分析管理和产品规划培训课程 课程背景 营销大师科特勒指出：“以市场为导向、以客户为中心”就是对市场需求的管理！市场需求管理是公司战略、市场计划、新产品开发的依据，决定了公司竞争力的延续，直接影响到公司效益。 但是：“有价值的客户需求在哪里，对有价值的需求如何进行汇总、分析。”目前大量的理论体系到此为止，如何在实际的操作层面上进行下去？如何执行？根据权威机构统计：项目缺陷的56％来源于需求定义错误，80％的缺陷修复成本用于修复需求导致的错误，需求的正确与否直接影响产品开发周期、产品开发成本，甚至直接决定产品最终的市场成败。 通过和众多国内科技企业接触，我们发现这些企业中普遍存在如下问题： 1.缺少完备的需求收集、汇总、分析机制，“公司神经末梢与大脑失去联系”； 2.产品开发过程需求工作持续时间短，需求分析不充分；需求没有有效地分层分级，对不同阶段需求应该详细到什么程度没有明确的定义； 3.需求的表达不够结构化，充斥着“故事会”格式的需求，直接影响了不同团队对需求理解一致性； 4.产品开发闭门造车，关注技术，不关注客户； 5.产品开发出来才找客户、找卖点； 6.不清楚业界众多需求分析工具如何在不同需求分析阶段进行恰当运用等； 本课程结合以上企业在市场需求管理中存在的问题进行深入的探讨，结合多年企业的实践和研发管理咨询的案例，就企业在市场需求的收集、整理、归类、分析、分解与分配、执行与验证等环节的问题展开深入的讲解，并分享大量企业的案例。 课程特色 课程的实践性：讲师从事过市场需求管理的工作多年，同时完成过近10个咨询项目，通过大量的案例和演练，让学员非常便于理解；具体的操作方法和工具：课程涉及的市场需求分析和市场需求管理的方法和工具十分具体，操作性非常强；讲师独特的专业背景：讲师都是从研发做起，在知名企业担任研发中高层领导，并且在成功的企业有成功的实践经验。 培训收益 1.了解研发需求工程过程与其他研发流程体系的接口关系； 2.掌握从市场角度进行有效的客户需求收集的机制和方法，筛选高质量的客户需求； 3.掌握对客户需求进行整理、分类、分析的方法，提高各个角色对需求理解的一致性，最终形成产品包需求，明确产品的竞争优势与卖点； 4.掌握外部需求和内部需求一体化管理的机制，从而降低产品的端到端生命周期成本； 5.掌握对产品包需求进行分解和分配，确保需求与设计协同一致，减少模块间耦合的方法； 6.掌握对客户需求、产品包需求、设计需求进行持续验证和跟踪的机制和方法； 7.掌握构建需求收集长效机制，提升公司整体需求管理能力的机制和方法； 8.掌握支撑研发需求工程各个阶段工作运作的工具和操作方法。 课程大纲 一、例分析：某案例公司市场之路
需求开发和管理流程范例
需求开发和管理流程范例 目录 1.目的 (3) 2.适用范围 (3) 3.名词和缩略语 (3) 4.角色和职责 (3) 5.过程综述 (5) 5.1. 流程图 (5) 5.2. 过程说明 (5) 6.过程活动 (6) 6.1. 活动一：获取用户需求 (6) 6.2. 活动二：建立系统需求 (7) 6.3. 活动三.需求分析与建模 (9) 6.4. 活动四.形成需求规格说明 (10) 6.5. 活动五.需求验证 (11) 6.6. 活动六：需求变更 (12) 6.7. 活动七：需求跟踪 (12) 7.过程度量与改进 (15) 8.过程裁剪指南 (15) 9.相关文件 (15)
10.质量记录 (16) 11.附录 (17) 11.1. 附录1：需求优先级说明 (17) 11.2. 附录2：需求状态说明 (17)
1.目的 本程序文件定义了本组织的需求与管理的过程，目的是实现有计划地收集、分析顾客的需求，并保证所有共利益者在项目进展过程中始终保持对需求一致的理解和承诺。 2.适用范围 本过程适用于公司所有合同项目和自主研发项目。 3.名词和缩略语 4.角色和职责
5.1.流程图 5.2.过程说明 需求开发与管理过程包括首先获取用户需求，然后对用户需求进行分类和整理，形成系统需求。通过对系统需求进行分析和建模，形成需求规格说明书，并将分析后的需求以模型或原型方法与用户进行确认，以此建立设计开发基础。最后采用原型、测试验证、评审等方式验证需求。同时，在开发活动中有序的管理需求变更，并通过需求跟踪确保需求的可追溯性和一致性。
6.1.活动一：获取用户需求 通过与用户交流、对现有系统的了解以及对项目任务的分析，开发、捕获和修订用户的需要。 6.1.1.进入准则 经过市场扫描活动、售前支持、客户反馈等活动，产品经理经过基本分析，确定要进行某产品的开发和较大升级； 6.1.2.输入 市场分析报告、售前和售后服务相关记录 6.1.3.任务 任务1：产品市场扫描。市场服务部会同产品经理针对特定产品进行市场扫描工作，主要包括与该产品相关的其他产品的名称、主要功能、市场情况；产品的领域，相关标准情况；产品主要涉及的技术领域和技术发展概况。产品经理根据市场扫描的结果确认是否需要进行产品开发和升级。 任务2：需求调研。产品经理根据《需求调研规程》组织相关人员实施需求调研活动，形成相关调研记录和《需求特性列表》。评审小组对调研结果实施结构化审查。 任务3：产品路线图设计。产品经理根据产品的需求特性列表和市场情况初步确定产品功能特性的优先级，优先级划分参见附录1，并且将优先级的划分与高级经理进行沟通，得到初步的确定后，对需求特性列表按照优先级进行分类整理，形成《产品路线图》。 对于项目而言，此任务可以演化成考虑项目分阶段实施的需求划分。 6.1.4.输出 《需求特性列表》、《产品路线图》 6.1.5.退出准则 《需求特性列表》通过审核，与高级经理沟通后初步明确项目经理
软件项目的需求开发与管理
软件项目的需求开发与管理需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的存在问题，有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。 本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。 1? 什么是软件需求和需求工程 软件需求的定义 在IEEE软件工程标准词汇表(1997年)中定义软件需求为： （1）用户解决问题或达到目标所需的条件或能力。 （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。（3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。 实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。 需求工程的定义 需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情
研发部需求开发流程管理
研发部需求开发流程管理
管理目标 1、所有关系人清晰明确地了解项目的需求和 期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。 2、项目管理三要素平衡（时间/成本/质量）， 即开发项目按需按时按质的完成。 3、目标：功能满足需求，设计支持变化，开发 快速迭代，成果持续交付。 执行概述 1、建立有效的工作流程保证项目的顺利进行， 初期使用传统RUP过程，引入部分敏捷方法，团队磨合完成后逐步实现敏捷开发全流程管理。 2、明确项目目标，制定具有可行性的项目计 划，有效明确的分解项目需求。 3、跟踪设计/开发/测试/回归/发布全流程，推 动项目按预定计划执行。 4、解决项目过程中出现的问题和冲突，一般集
中在需求不明/工作量或时长/开发难度/跨 部门协调等几个方面。 5、调动开发团队的积极性，创造力，推动团队 成员在项目过程中的学习成长。 6、风险识别、风险控制以及风险的预案。 项目管理 1、需求阶段 对项目进行技术可行性分析、技术评估、成本评估以及风险评估。 与需求提出方的代表进行需求讨论，明确项目的目标、价值。 确定项目范围、功能及优先级。 组建项目团队，特别要搞清楚项目的关键人。 项目启动会议，相关的关系人都必须参加。 2、设计阶段 根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统
设计；文档(包括系统用例、Demo、测试用例等)；评审会议。 设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。 该阶段交付成果需要进行评审。 3、执行阶段(开发和测试) 准备开发环境、测试环境。 跟踪，推动项目按计划进行。 项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。 按里程碑对阶段成果进行评估，以确保该阶段完成的质量。 代码审核，包括CS审核、SQL审核、WEB 审核等。 对需求变更进行控制管理。 测试阶段BUG响应及改进、收集反馈意见。 对项目风险进行管理。 4、发布阶段 包括制定项目发布计划，用户培训，发布上
产品需求分析与需求管理——如何搞定市场需求
产品需求分析与需求管理——如何搞定市场需求 主讲：董奎（十多年高科技企业的研发与管理实践经验，在某著名高科技企业工作期间，先后担当项目经理、系统工程师、产品经理、软件部经理） 课程对象：企业CEO/总经理、研发总监、研发经理/项目经理/技术经理/产品经理、产品规划专家等。 授课方式：讲师讲授+视频演绎+案例研讨+角色扮演+讲师点评。 【课程背景】 通过和众多国内科技企业接触，发现这些企业中普遍存在： 1、技术很牛，但最终倒闭的公司一大推；被技术人员嗤之以鼻的公司，反而活的还不错 2、研发从早忙到晚，产品开发的不少，但市场成功的产品屈指可数，开发的越多，死得越快 3、产品开发闭门造车，关注技术，不关注客户；产品开发出来才找客户、找卖点 4、了解市场的不懂技术，懂技术的不了解市场，不知道需求应该谁负责 5、需求准确把握决定产品成败，但没有人关注需求，即使偶尔想关注也不知道如何关注 6、需求的表达不够结构化，充斥着“故事会”格式的需求，直接影响了不同团队对需求理解的一致性 7、缺少完备的需求收集、汇总、分析机制，“公司神经末梢与大脑失去联系” 8、不能从自身能力提升来引导客户需求，反而天天在抱怨客户需求经常变动 9、针对需求大家“吵成一锅粥”：公司与客户吵，市场与开发吵，开发与测试吵，…… 不能满足客户需求、给客户创造价值，再牛的技术也没有价值。根据权威机构统计项目缺陷的56%来源于需求定义错误，80%的缺陷修复成本用于修复需求导致的错误，把技术变成金钱的不二选择关注、锁定、满足市场需求，创造客户价值。【课程重点】 1、如何确定目标客户，如何分析需求关系人？
2、如何从市场（客户）角度进行有效的客户需求收集？ 3、围绕产品成功2个核心因素差异化+成本优势，整理产品需求 4、如何对客户需求进行整理和分析，形成产品包需求？ 5、如何基于产品需求与竞争友商对比分析，确定我们的核心诉求，形成产品概念？ 课程贯穿案例分享，详细讲解目标客户?客户要求?客户需求?产品包需求?产品概念确定全过程，详细讲解把技术转变为金钱的方法和工具（利润区、回溯分析、决策模型分析、KJ、$APPEALS、BSA、概念定义7个核心秘诀、破坏性创新的3石蕊实验、SweetPoint模型、基于不同产品生命周期的12个创新思路等），提升产品的竞争力，确保市场成功、财务成功。 【课程价值】 1、掌握从市场角度进行有效的客户需求收集的机制和方法，筛选高质量的客户需求； 2、掌握对客户需求进行整理、分类、分析的方法，提高各个角色对需求理解的一致性，最终形成产品包需求，明确产品的竞争优势与卖点； 3、掌握外部需求和内部需求一体化管理的机制，从而降低产品的端到端生命周期成本； 4、掌握产品核心诉求的提炼方法，确定有吸引力的产品概念； 5、掌握支撑研发需求工程各个阶段工作运作的工具和操作方法； 【培训内容】 一、案例分享 二、六个基本概念 1、什么是客户？ 1)客户、用户、目标客户、潜在客户、可以送给竞争友商的毒药客户 2、什么是需求？ 1)WANTS/NEEDS/DEMANDS、真假需求、客户需求、用户需求、产品需求、设计需求、需求规格、技术需求、非技术需求 2)案例：某运营上广告折射对需求五层次的理解 3、需求工作的2个基本点：
研发部需求开发规程管理
精心整理 管理目标 1、所有关系人清晰明确地了解项目的需求和期望，努力做到满足项目所有关系人的不同需求；项目关系人包括：项目团队成员和项目团队外(内部/外部客户，内部/外部合作伙伴，经销商/客户等)。 2、项目管理三要素平衡（时间/成本/质量），即开发项目按需按时按质的完成。 3、目标：功能满足需求，设计支持变化，开发快速迭代，成果持续交付。 执行概述 1、 2、 3、跟踪设计/开发/测试/回归/ 4、/跨部门协 调等几个方面。 5、 6、风险识别、风险控制以及风险的预案。 项目管理 1、需求阶段 2 根据确认后的软件需求规格说明书，制定项目进度计划，工作任务分解(WBS)；资源申请，项目涉及到的开发资源、测试资源、设计资源(包括人员和软硬件资源)；数据库设计；系统设计；文档(包括系统用例、Demo、测试用例等)；评审会议。 设计阶段结果交付一般为系统用例/系统原型/系统设计文档(概要设计和详细设计)/数据库设计文档等。 该阶段交付成果需要进行评审。 3、执行阶段(开发和测试) 准备开发环境、测试环境。
跟踪，推动项目按计划进行。 项目成员以日报/项目负责人以周报的形式通报各关系人当前项目的进展情况。 按里程碑对阶段成果进行评估，以确保该阶段完成的质量。 代码审核，包括CS审核、SQL审核、WEB审核等。 对需求变更进行控制管理。 测试阶段BUG响应及改进、收集反馈意见。 对项目风险进行管理。 4、发布阶段 包括制定项目发布计划，用户培训，发布上线。 5、试运行阶段 数据监控(日志、服务器状态) 定情况执行补丁升级。 6、收尾阶段 产品交付，项目总结会。 常见问题 1、开发时间的估算 算，通常单个模块开发时间取决于以下因素： 1 2(包括对框架和应用的熟悉程度)。 3 开发者没有相关的代码可以参考，自己也没有经验， 1、在划分好模块后，首先项目管理人员预先估算各个模块所需要的开发时间。 2、召集所有开发人员，讨论模块的分配和开发时间估算。将划分好的模块，分配给开发人员，如状况允许可允许开发人员自主选择以提高开发人员的主动性和参与性。分配模块的时为确保开发的速度和质量，基本原则如下： A、类似的模块由同一人负责开发，比如用户信息的增删改应由同一开发者负责。这样开 发者对相关逻辑会比较熟悉，代码/接口的定义也会相对明确，沟通的成本低，相应可以降低功能实现的缺陷概率。 B、技术难度较大的模块由技术水平比较高的人负责。 C、业务逻辑比较复杂的由对业务逻辑比较了解的人负责。
需求开发与管理过程
密级：普通 标识:S_RD_XQKFYGLGC 版本号：2.0 分册：第1册/共1册 需求开发与管理过程 湖南创博龙智信息科技股份有限公司 湖南创博龙智信息科技股份有限公司对本文件资料享受著作权及其它专属权利，未经书面许可不得将该等文件资料（其全部或任何部分）披露予任何第三方，或进行修改后使用。
文件更改摘要：
目录 1.目的/方针 (3) 2.范围 (3) 3.术语 (3) 4.角色与职责 (3) 5.入口准则 (3) 6.输入 (3) 7.流程图 (4) 8.主要活动 (4) 8.1.需求获取 (4) 8.1.1.明确所需获取信息的来源与渠道（Where） (5) 8.1.2.获取需求（How） (5) 8.1.3.需求获取资料的保管 (7) 8.1.4.编写用户需求规格说明书 (7) 8.2.需求分析 (7) 8.2.1.结构化分析方法 (7) 8.2.2.基于用例的分析方法 (8) 8.3.需求定义 (9) 8.3.1.定义需求的优先级 (9) 8.3.2.编写《需求分析说明书》 (10) 8.4.需求确认 (10) 8.4.1.需求评审 (10) 8.4.2.需求承诺 (11) 8.4.3.建立需求基线 (11) 8.5.需求变更 (11) 8.5.1.需求变更申请................................................................. 错误！未定义书签。 8.5.2.需求变更的实施 (12) 8.6.需求跟踪 (12) 8.6.1.建立需求跟踪矩阵 (12) 8.6.2.需求跟踪矩阵的维护与使用 (12) 9.输出 (12) 10.出口准则 (13) 11.资源 (13) 12.引用文档 (13)
产品需求分析与需求管理
产品需求分析与需求管理 －－如何搞定市场需求通过和众多国内科技企业接触，发现这些企业中普遍存在： 1. 技术很牛，但最终倒闭的公司一大推；被技术人员嗤之以鼻的公司，反而活的还不错 2. 研发从早忙到晚，产品开发的不少，但市场成功的产品屈指可数，开发的越多，死得越快 3. 产品开发闭门造车，关注技术，不关注客户；产品开发出来才找客户、找卖点 4. 了解市场的不懂技术，懂技术的不了解市场，不知道需求应该谁负责 5. 需求准确把握决定产品成败，但没有人关注需求，即使偶尔想关注也不知道如何关注 6. 需求的表达不够结构化，充斥着“故事会”格式的需求，直接影响了不同团队对需求理解的一致 性 7. 缺少完备的需求收集、汇总、分析机制，“公司神经末梢与大脑失去联系” 8. 不能从自身能力提升来引导客户需求，反而天天在抱怨客户需求经常变动 9. 针对需求大家“吵成一锅粥”：公司与客户吵，市场与开发吵，开发与测试吵，…… 不能满足客户需求、给客户创造价值，再牛的技术也没有价值。根据权威机构统计项目缺陷的56%来源于需求定义错误，80%的缺陷修复成本用于修复需求导致的错误，把技术变成金钱的不二选择关注、锁定、满足市场需求，创造客户价值。 本课程重点讲解： 1. 如何确定目标客户，如何分析需求关系人？ 2. 如何从市场（客户）角度进行有效的客户需求收集？ 3. 围绕产品成功2个核心因素差异化+成本优势，整理产品需求 4. 如何对客户需求进行整理和分析，形成产品包需求？ 5. 如何基于产品需求与竞争友商对比分析，确定我们的核心诉求，形成产品概念？ 课程贯穿案例分享，详细讲解目标客户→客户要求→客户需求→产品包需求→产品概念确定全过程，详细讲解把技术转变为金钱的方法和工具（利润区、回溯分析、决策模型分析、KJ、$APPEALS、BSA、概念定义7个核心秘诀、破坏性创新的3石蕊实验、Sweet Point模型、基于不同产品生命周期的12个创新思路等），提升产品的竞争力，确保市场成功、财务成功。 一、案例分享 二、六个基本概念 1. 什么是客户？ 1) 客户、用户、目标客户、潜在客户、可以送给竞争友商的毒药客户 2. 什么是需求？ 1) WANTS/NEEDS/DEMANDS、真假需求、客户需求、用户需求、产品需求、设计需求、需 求规格、技术需求、非技术需求 2) 案例：某运营上广告折射对需求五层次的理解 3. 需求工作的2个基本点： 1) 差异化 2) 成本优势 4. 需求工程全过程： 1) 需求收集→需求整理→需求分析→概念确定→需求分解→需求实现与验证 5. 官方体系对需求的定义： 1) RM（目的、关键实践、典型输出） 2) RD（目的、关键实践、典型输出） 6. 产品经理3个核心素质特征：
需求开发与管理过程(Req. Development Mgt. Process)
Req. Development & Mgt. Process 需求开发与管理过程 Prep分配需求ed by 拟制陈刚 Date 日期 2006-05-16 Reviewed by 评审人SEPG team Date 日期 2007-4-20 Approved by 批准田松涛 Date 日期 2007-4-24
Revision Record 修订记录
Table of Contents 目录 1Purpose 目的 (5) 2Scope 范围 (5) 3Abbreviations and Acronyms 术语和缩略语 (5) 4Policy 方针 (5) 5Process Description 过程描述 (5) 5.1Roles and Responsibilities 角色和职责 (6) 5.2Entrance Criteria 入口准则 (6) 5.3Input 输入 (6) 5.4Activities 活动 (6) 5.4.1Summarize 总述 (6) 5.4.2Flow Chart 流程图 (7) 5.4.3Requirements Development and Validation 需求开发及确认 (8) 5.4.4Trace Requirements and Requirements Management 需求跟踪和管理 (10) 5.5Output 输出 (11) 5.6Exit Criteria 出口准则 (11) 6Resource and Tools 资源与工具 (11) 7Configuration Management and Assets 配置管理和资产 (11) 8Training 培训 (11) 9Process Measurement 过程度量 (11) 10Tailoring Guidelines 裁剪指南 (12) 11Verification 验证 (12) 12Related Process 相关过程 (12) 13Reference Materials 参考文献 (12)
需求开发与管理
需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的存在问题，有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。 本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。 1 什么是软件需求和需求工程 1.1 软件需求的定义 在IEEE软件工程标准词汇表(1997年)中定义软件需求为： （1）用户解决问题或达到目标所需的条件或能力。 （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。 （3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。 1.2 需求工程的定义 需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。这四个阶段不一定是遵循线性顺序的，他们的活动是相互独立和反复的。需求管理是软件项目开发过程中控制和维持需求约定的活动，它包括：变更控制、版本控制、需求跟踪、需求状态跟踪等工作。 2 需求分析的风险 由于需求分析的参与人员、业务模式、投资、时间等客观因素的影响和需求本身具有主观性和可描述性差的特点，因此，需求分析工作往往面临着一些潜在的风险。这些风险主要表现在： （1）用户不能正确表达自身的需求。在实际开发过程中，常常碰到用户对自己真正的需求并不是十分明确的情况，他们认为计算机是万能的，只要简单的说说自己想干什么就是把需求说明白了，而对业务的规则、工作流程却不愿多谈，也讲不清楚。这种情况往往会增加需求分析工作难度，分析人员需要花费更多的时间和精力与用户交流，帮助他们梳理思路，搞清用户的真实需求。 （2）业务人员配合力度不够。有的用户日常工作繁忙，他们不愿意付出更多的时间和精力向分析人员讲解业务，这样会加大分析人员的工作难度和工作量，也可能导致因业务需求不足而使系统无法使用。
需求开发流程管理规定
需求开发流程管理规定 1. 目的 通过需求开发流程的规定，规范公司软件项目的需求开发和管理活动，提高需求质量，降低开发成本，改进系统质量。 ，
4. 流程图 图1：需求开发流程图
5. 主要活动 需求定义的目的是需求提出人通过收集、调查与分析，获取用户业务需求并定义需求。需求定义的主要活动包括：需求收集、需求分析&定义。 需求管理的目的是在需求方与程序组之间建立对需求的共同认识和理解，维护需求与程序开发成果的一致性，并控制需求的变更。需求管理的主要活动包括：需求评审确认、需求变更、需求跟踪控制。 在需求文档中，一般取二级类别进行标识。 5.1.3 需求优先级 需求分析员应确定每个需求的优先级，需求的优先级判定标准如下：
●确保所描述的需求可以通过适当的手段得到验证，即需求的可测试性； ●考虑了各个层次的需求影响，确定了需求的优先级，以确保需求的可行性。 提醒：对于版面调整、活动等不需要做过多业务流程更改的需求，采用《程序需求表》进行填写。 5.2 需求评审确认及开发流程 需求评审是指程序开发方和需求提出方共同对《立项需求说明书》进行评审，双方对需求与商业目的达成共识。
在需求说明书生成后，需求分析员将文档提交给需求受理人，由受理人进行初审，确保文档的正确性和合理性，并符合文档编写规范。 5.2.1 需求评审 评审的目的在于：使需求文档达到易读、无歧义、一致、必要、完整、可实现、可验证。 需求受理人（一般为部门总监，各个地区分站由技术中心受理）对提交的需求文档进行初审通过后，由信息技术中心组织和安排需求的评审工作：确定评审时间、地点、评审人员和其他参加人员。至少应包含以下成员： ●评审组长：总裁及总裁办相关领导、信息技术总监； ●评审成员：项目经理、程序员及其他相关人员； ●输入：《立项需求说明书》初稿 ●输出：《评审结果报告》 当需求文档评审通过后，程序开发方和需求提出方应须进行书面签字确认，使之生效。之后若需要调整需求，则须走需求变更控制流程。 未经书面确认的需求开发，若发生需求分歧，由未签字确认方及其上级承担主要责任。 经书面确认的需求开发，若发生预期需求与开发实现的功能不一致而影响开发质量的，责任归属 界定： A.因需求不明确、阐述遗漏、描述错误等，且后期没有对应的需求变更记录备案，而造成实现 的功能与预期需求不一致，由需求方承担主要责任。 B.因需求不明确、阐述遗漏、描述错误等，而后期存在对应的需求变更记录备案，而造成实现 的功能与预期需求不一致的，由程序开发方承担主要责任。 5.3 需求变更 对一个软件项目来说，无论最初的需求分析有多么明确，开发过程中的需求变化也还是不可避免。这主要有以下几种原因： 1. 系统所应用的外部环境发生变化； 2. 随着对软件的熟悉和应用，又提出新的需求； 3. 进行需求分析时未能彻底分析原始需求，或分析错误； 4.在开始时不能很全面的知道所需软件的功能。 需求变更的影响：对项目研发而言，变更需求意味着有可能需要重新分配任务、修改前期工作成果、调整工作计划和项目预算等。 只有当需求变更带来的好处大于坏处时，变更需求才是有意义的，但也须遵循变更控制流程：申请→审批→执行；如果需求变更带来的坏处大于好处，则应拒绝变更。 需求受理人应适当拒绝一些不合理的变更。如：提出的变更不是由于程序开发方的过错引起的，此变更可能造成程序开发方占用额外的资源或成本，而需求方又不愿给出额外资源对变更进行处理等。 变更控制流程如图所示，主要包括：变更申请、评审和审批、填写执行记录。
需求开发流程
密级：内部公开 文档编号：KKCQ-Proc-RDM 版本号：V1.0 分册名称：第1册/共1册 需求开发与管理说明
文档更改摘要：
1. 目的 通过此需求开发流程的定义，规范公司内部项目的需求开发和管理活动，提高需求质量，从而提高需求任务处理率，降低开发成本，改进系统质量。 通过对业务部提交的需求进行评审，确保需求的正确性和合理性，获得需求的承诺；控制需求的变更，并确保项目工作成果与需求的一致性。 2. 范围 适用于公司内部开发项目及已经通过《商业需求确认书》的项目，如未通过《商业需求确认书》，技术中心暂时无法参与需求立项，评审，分析等流程。附件一：《商业需求确认书》 3. 术语 4. 角色与职责 5. 流程图
图1：需求开发流程图 6. 主要活动 需求定义的目的是需求提出人通过收集、调查与分析，获取用户业务需求并定义需求。需求定义的主要活动包括：需求收集、需求分析&定义。 需求管理的目的是在需求方与程序组之间建立对需求的共同认识和理解，维护需求与程序开发成果的一致性，并控制需求的变更。需求管理的主要活动包括：需求评审确认、需求变更、需求跟踪控制。 6.1需求定义 由于在实际情况下，大部分原始需求都未完整地讲述其业务需求，需求获取的质量，对后续的需求分析和需求定义工作将会产生重大影响。 在完成需求收集所得到的记录与资料的分析与整理后，产品经理应对需求进行分类、排优先级等。 6.1.1 标识需求与命名规则 为了便于需求文档的统一管理，更好的识别每个项目的需求，需要明确需求文档的命名规则，具
体格式为： [需求年月]-[项目类别]-[用途类别] 如，201310-综合信息项目-活动需求； 6.1.2 需求分类 在需求文档中，一般取二级类别进行标识。 6.1.3 需求优先级 时，正确地对需求实现的范围或实现的优先程度做出取舍。
软件方案的需求开发与管理
软件项目的需求开发与管理 需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。虽然如此，在项目开发工作中，很多人对需求的认识还远远不够，从本人参与或接触到的一些项目来看，小到几十万元，大到上亿元的软件项目的需求都或多多少的存在问题，有的是开发者本身不重视原因、有的是技术原因、有的是人员组织原因、有的是沟通原因、有的是机制原因，以上种种原因都表明做好软件需求开发是一项系统工作，而不是简单的技术工作，只有系统的了解和掌握需求的基本概念、方法、手段、评估标准、风险等相关知识，并在实践中加以应用，才能真正做好需求的开发和管理工作。 本文将通过介绍关于软件需求的基本知识和个人在实际工作中总结的一些经验，帮助读者了解软件需求，学习需求开发的一些基本方法，避免因需求原因而导致的项目失败。 1 什么是软件需求和需求工程 1.1 软件需求的定义 在IEEE软件工程标准词汇表(1997年)中定义软件需求为： （1）用户解决问题或达到目标所需的条件或能力。 （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力。（3）一种反映上面(1)或(2)所描述的条件或权能的文档说明。 实通俗的讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目标、以及实现这些目标所需要的条件，它是一个程序或系统开发工作的说明，表现形式一般为文档形式。 1.2 需求工程的定义 需求分析的过程，也叫做需求工程和需求阶段，它包括了需求开发和需求管理两个部分。需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为四个阶段：情况获取、分析、制订规格说明和评审。这四个阶段不一定是遵循线性顺序的，他们
产品需求开发与需求管理-王小刚
产品需求开发与需求管理 主办单位：一六八培训网 时间：2016年5月27-28日地点：北京讲师：王小刚 价格：3600元/人(包授课、资料、午餐、茶歇、会务和税务费用) 课程背景 随着时代背景的变迁，互联网信息技术的不断发展，研发企业在全球范围内所面临的竞争也在不断的加剧，如何才能在强手如林的竞争环境中脱颖而出，保持并不断提升企业的竞争力? 笔者认为最为根本的依靠还是看研发企业是否具备优秀的产品开发能力，能否做到持续领先于竞争对手向市场推送满足客户需求的产品，唯有如此，才能保证产品市场份额和企业利润的可持续发展，但说时容易做时难，如今国内大部分研发企业在产品开发能力上依然有大幅的提升空间，尤其是在产品需求开发与管理上，您是否能够把有限的资源全部投放在正确的需求上；即使您做到了这一点，那是否在产品服务或者用户体验需求上继续探索，寻找着力点；即使您又做到了，是否能够在产品开发过程中对需求进行高效科学的管理，保证正确的需求能够快速、准确的实现、并及时推送给您的客户，如果这几方面还做的不够优秀，本课程将会对您大有益处。 本次需求管理课程的两个关键词是”开发与管理“，需求开发的目的是让我们的企业能够”做正确的事“，这是成功或失败的源头，重要性毋庸置疑，但光有这个源头，还不足以让我们走在竞争对手的面前获得成功，我们企业还必须要具备“把事情做正确的能力”，让正确的需求始终正确，而且能够高效的实现，最终获得市场和客户认可，这正是需求管理的范畴。所以需求开发与需求管理相辅相成，缺一不可，本次课程全面系统的从需求开发与需求管理两个维度进行展开，结合产品市场管理和产品开发管理两个体系的实践活动进行详细的讲解。 培训收益 1. 深度理解产品需求的价值和范围 2. 全面、系统的学习产品需求开发与管理的过程，拒绝做”需求管理的临时工” 3．掌握产品需求开发与管理组织、角色、流程、能力的建设思想 4. 掌握产品需求开发与管理与集成产品开发体系的关系和接口建设
软件需求分析与需求管理
软件需求分析与需求管理 时间地点：2010年10月29-30日深圳 课程价格：3200 课程详细： 课程背景 在经济蓬勃发展的今天，企业的信息化需求变化非常快，这对软件企业提出了严峻的挑战，对需求的快速反应能力体现了一个软件企业的核心竞争能力，目前国内软件企业软件开发过程远未成熟，却还要常常面临国外同行的竞争。如何在这样一个激烈的市场竞争环境中既积累产品技术、又能够迅速把握市场机会，软件需求开发和管理能力成为了关键。 课程除了介绍软件需求开发和需求管理过程，还利用讲师实际的经验，与学员共同分析本企业需求工作中的问题，并特别针对目前需求工作中的常见难点进行分析，包括如何在需求工作中与客户进行主动合作、如何制作需求驱动的软件开发计划、如何在不断满足客户需求的同时积累企业的核心产品能力。课程不仅仅给学员在需求工程上一个完整的整体认识、还培训了学员在需求开发和需求管理的实际实施能力，包括一些难点实际操作能力。 课程结合行业环境和软件企业具体发展状态来讲述软件需求开发与需求管理，对不同态势下的软件企业的需求工作具有实际的参考价值。 课程特色 o 课程系统全面，包括了需求的开发和需求管理、需求驱动的软件开发计划，共10个模块，并配有相应的案例、练习和模板。 o 课程设计根据业界最佳实践和讲师实际经验而设计，避免陷入一般知识理论介绍。 o 简单适用的管理工具与方法，回绝复杂费解的理论。 o 课程中互动式教学、大量的小案例、分析大案例和学员亲自演练，有助于学员理解。 o 丰富的模版、Checklist展示，有助于企业用于具体工作。 o 讲师12年软件产品开发、技术管理、人员管理的实践经验。 o 讲师在业界优秀企业工作时的切身实践体会。 培训收益 o 解决问题： l 有些项目，前期需求调研、设计开发测试都很顺利，但一到交付，就反复修改，甚至推倒重来，如何在一开始就
软件项目的需求开发和管理
摘要 需求开发与管理是软件项目中一项十分重要的工作，据调查显示在众多失败的软件项目中，由于需求原因导致的约占到45%，因此，需求工作将对软件项目能否最终实现产生至关重要的影响。如何从各种各样的应用专业领域中特别是直接从最终用户处捕获需求，并完整、准确地予以描述与分析，需求工程成为研究的热点之一。 本文通过对需求工程的基本概念、需求开发和管理中的主要风险和对策进行研究和总结，希望在实践中加以应用，真正做好需求的开发和管理工作。 关键字：软件项目、需求工程、需求分析、需求开发、需求管理、X围管理、X围变更控制
目录 1软件需求和需求工程3 1.1软件需求的基本概念3 1.2软件需求的重要性3 1.3需求工程的基本概念4 1.4需求开发过程域4 1.5需求管理过程域5 1.6需求工程的一些感悟5 2需求开发和管理的主要风险6 3需求开发和管理的主要对策6 3.1建立需求开发和管理工作机制需考虑的几个因素7 3.2需求开发和管理流程7 3.2.1需求调查7 3.2.2细化用户需求8 3.2.3撰写需求说明书8 3.2.4需求确认9 3.2.5需求跟踪10 3.2.6需求变更控制10 4总结13
软件项目的需求开发和管理 1软件需求和需求工程 1.1 软件需求的基本概念 在IEEE软件工程标准词汇表(1997年)中定义软件需求为： 1)用户解决问题或达到目标所需的条件或能力。 2)系统或系统部件要满足合同、标准、规X或其它正式规定文档所需 具有的条件或能力。 3)一种反映上面1)或2)所描述的条件或权能的文档说明。实通俗的 讲，“需求”就是用户的需要，它包括用户要解决的问题、达到的目 标、以及实现这些目标所需要的条件，它是一个程序或系统开发工 作的说明，表现形式一般为文档形式。 所以我们可以理解，软件需求来源于用户的一些“需要”，这些“需要”被分析、确认后形成完整的文档，该文档详细地说明了产品“必须或应当”做什么。 1.2 软件需求的重要性 软件需求是整个产品链的源头，需求工作的优劣将直接影响到产品的设计，生产，销售和维护的全过程。就像一条河流，如果源头被污染了，那么整条河流也就被污染了。Frederick Brooks在他的经典文章“No Silver Bullet”是这样描述需求的重要性的：开发软件系统最困难的部分就是准确说明开发什么。最困难的概念性工作是编写出详细的需求，包括所有面向用户、面向机器和其它软件系统的接口。此工作一旦做错，将会给系统带来极大的损害，并且以后对它修改也极为困难。