怎么样做好需求分析？
IT168网站原创
　作者: 沉思　编辑:
&&& 【IT168 信息化】&&& ---对商业用户来说，他们后面是成百上千个供应商，前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客，如何做好精细到一个小小调料包的进、销、调、存的商品流通工作，这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目，正是软件开发成功的关键所在。&&& ---经理：&我们要建立一套完整的商业管理软件系统，包括商品的进、销、调、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过扫条码实现销售，管理人员能够随时查询门店商品销售和库存情况。另外，我们也得为政府部门提供关于商品营运的报告。&&&& ---分析员：&我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。&&&& ---经理觉得奇怪：&我不是刚告诉你我的需求了吗？&&&& ---分析员：&实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的，这样可节省很多时间。&&&& ---经理：&业务人员都在招商。他们非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？&&&& ---分析员尽量解释从用户处收集需求的合理性：&如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。&&&& ---经理坚持道：&行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。&&&& ---风险躲在需求的迷雾之后&&& ---以上我们看到的是某客户项目经理与系统开发小组的分析人员讨论业务需求。在项目开发中，所有的项目风险承担者都对需求分析阶段备感兴趣。这里所指的风险承担者包括客户方面的项目负责人和用户，开发方面的需求分析人员和项目管理者。这部分工作做得到位，能开发出很优秀的软件产品，同时也会令客户满意。若处理不好，则会导致误解、挫折、障碍以及潜在的质量和业务价值上的威胁。因此可见&&需求分析奠定了软件工程和项目管理的基础。&
第1页：第2页：
第3页：第4页：
大学生分期购物销量榜
已有条评论
IT168企业级如何在前期做好需求分析_项目管理文章库_项目管理者联盟
适合敏捷开发项目
敏捷项目管理最佳实践
重视项目商业分析
商业价值与需求分析能力
信息系统项目管理师
系统集成项目管理工程师
单项目管理经典指南
年轻项目经理首选
大型复杂项目全球标准
定位高级项目管理层
产品管理国际认证
全球产品管理最佳实践
链接战略与项目
实现组织资源投资回报
如何在前期做好需求分析
作者：佚名 &
提交人： &
属性：提交人转载 &
发布时间：<font color="#17-7-3 &
点击：<font color="#
　　需求分析是项目开发的基础，基础打的牢不牢直接关系到后面所有的工作，是项目实施成败的关键。项目管理者联盟
　　一般情况下，项目前期的需求分析是做了，但是做的力度不够，并没有解决这样的项目是不是真就是客户想要的。造成这种状况的原因主要分为三种情况：一是客户本身说不清楚;二是需求自身经常变动;三是分析人员或客户理解有误。由此就会造成项目开发过程中需求不断变更、成本增加、工期延长等问题，使客户得不到满意，员工得不到安慰。项目管理者联盟
　　a) 需求分析是整个项目管理中需要重点控制的几个关键节点之一，首先思想上一定要重视。项目管理者联盟
需求分析报告的编写者要参与到需求的搜集工作中，准确领会客户的意图，并转化成软件能够实现的功能。对于说不清楚需求的客户，要善于问关键问题，引导客户提出自己的需求。可以采取的措施是事先编制一个问卷调查之类的文档，详细列举需要客户回答的问题，以便防止遗漏。项目管理者联盟
需求报告的编写者要能够对客户需求进行深入分析，区别出哪些需求存在日后变更的可能，哪些需求属于相对固定的，哪些需求能够实现，哪些需求需要变通才能实现，以便于指导后面的功能设计。项目管理者联盟
需求分析报告对功能细节的描述不能有歧义，描述一定要全面、准确，防止开发方和客户只见对同一个问题有两个截然不同的理解。可以通过评审，用大家的力量来避免这种情况发生。club.mypm.net
　　e)需求报告的每个关乎功能的描述都要让客户明白和理解，客户在理解之上的确认才能够保证日后一旦出现问题不致出现双方互相推托责任纠缠不清的情况。项目管理者联盟
需求报告一定要经过一个有技术人员和业务人员参加的评审，要充分发挥团队的力量，重视每个人的才智，一个模块一个功能的逐一的过，让大家来共同找出需求报告里不合理的、有歧义的、不完善的、遗漏的等等问题。项目管理者联盟
帮助客户去理解提交给他的需求分析报告而不是只等签字，对于有能够用好几种方式实现的功能，尽量做到能让客户去比较和选择。不要让客户对报告中的部分产生歧义。只有客户对报告的完全的理解，才能在日后客户提出的修改被认为是需求变更的时候能够得到客户的理解。项目管理者联盟
　　h) 最后，需求分析报告一定要双方共同签字确认。项目管理者联盟
项目管理者联盟文章www.mypm.net<<上一页
[相关文章]
[网友互动]
? (203)项目管理评论杂.07-18? (92)项目管理者联盟07-03? (170)项目管理者联盟04-07? (287)项目管理者联盟03-06? (242)项目管理者联盟03-03? (649)项目管理者联盟01-10? (365)项目管理者联盟09-01? (2385)项目管理者联盟08-24
05-24[日志]
(36)05-24[帖子]
(2533)12-09[日志]
(28)03-29[帖子]
(644)03-15[帖子]
(472)10-22[帖子]
(1489)03-30[帖子]
(828)03-27[帖子]
[发表评论]
&&&&《文库》栏目为项目管理者联盟网站核心栏目，收录了十大行业项目管理文章5000余篇，囊括了项目管理五个阶段、九个知识领域的相关文章，是广大项目管理爱好者学习的知识库，欢迎大家发表原创文章、转贴文章，或直接。须联盟会员且后才能发表文章。
项目管理活动
主办单位：项目管理者联盟
时&&&&间：
地&&&&点：杭州&
电&&&&话：010-
邮&&&&件：
主办单位：项目管理者联盟
时&&&&间：
地&&&&点：上海&上海世博中心
电&&&&话：010-
邮&&&&件：
活动QQ群：<FONT SIZE="" COLOR="#FF275免费积累PDU,仅500人
原创排行榜
&&105&&84&&60&&52&&46&&44&&43&&38&&36&&34&&34&&33
-- 请选择 --
工程设计安装
汽车与零部件
通信与网络
能源煤电油
教育科研培训
商业物流贸易
媒体广告文体
---请选择更多专题---
项目经理职业生涯规划
PPP项目融资与项目管理
IT项目风险管理
工程项目成本管理
CMMI与项目管理
BT项目管理
ERP项目管理
项目经理职业生涯规划
项目管理与知识管理
项目组合管理
游戏研发项目管理
项目经理职业化
软件项目收尾管理
项目群管理
业主工程项目管理
医药研发项目管理
敏捷项目管理
项目经理领导能力培养
软件项目质量管理
研发团队绩效管理
工程项目合同管理
工程项目管理之EPC
虚拟团队管理
如何处理项目客户关系
软件项目风险管理
软件工程与项目管理
软件项目管理流程
项目管理的核心项目经理
软件外包项目管理
项目管理与企业文化
项目启动阶段的管理
企业项目化管理
手机研发项目管理
航天国防科研项目管理
企业多项目管理模式
项目融资之ppp模式
项目成本核算体系建设
组织级项目管理
项目管理绩效考核
项目管理办公室（PMO）
项目组织结构设计与选择
做好工程项目收尾工作
能源工程项目管理
基础设施建设工程管理
房地产项目管理
国际工程索赔与反索赔
工程招投标管理
建筑工程项目分包管理
项目融资模式―BOT
工程项目管理―代建制
项目管理承包PMC
如何做好项目沟通计划
工程项目之总承包管理
项目需求管理
技术人员转做项目管理
如何开好项目会议
项目经理的素质和职责
工作分解结构WBS
无处不在的项目管理
工程项目管理FIDIC
项目管理办公室（PMO）
--请选择更多访谈--
刘颖：慧与(中国)有限公司项目集经理
党新宁：国际项目组合经理PfMP获得者
李京基：百硕同兴项目咨询总监
高志兴：极客三个爸爸智能环境科技公司副总裁
张会斌：高远华信科技有限公司总经理
谢志杰：产品管理首席顾问
利镇有：跨国实业投资集团项目总监/高级顾问
高屹：项目管理者联盟研究院高屹副院长
马旭晨：中国项目管理研究院副院长
乔东：金融IT系统项目管理专家
高国伟：中国移动通信研究院产品管理经理
郭富才：深圳汉捷研发管理咨询公司副总经理
赖一飞：武汉大学经济与管理学院副教授
蒋卫平：复杂工程项目管理
檀爱民：先声药物
林志国：高阳科技
隋继周：中智慧聚
陈永涛：PMI
刘文圣：久其软件
马健锋：易和元通
包晓春：普华科技
郑杰：外专局
潘东：神州数码
苗云升：中国电子
王守清：清华大学
陈信祥 薛 岩
赵春明： 复斯管理
陈芳： 神州数码
孔争昕 ：上海奔驰
吴年发 ：中国寰球
张大鹏：神州数码
林森：天津辰达工程.
高学武：中国石化.
李福和：上海攀成德.
武晔卿：瑞迪航科技.
孙磊：上海锐科无线.
潘津平：天津天士力.
蔡培遥禾┛????.
曹蕾：第29届奥组委.
卢有杰：清华大学建.
石海东：北京视锐达.
崔惠钦：中国建筑工.
刘毛华：制造业项目.
占文松：制造业项目.
许江林：项目管理者.
符志民：中国航天科.
关一卓：中油吉林化.
王宇红：HP项目管理.
丁昌银：广州市建筑.
席相霖：中国科学院.
洪布坤：上海普华科.
丁荣贵：山东大学管.
侯岚：德创赛思工程.
王宇：英国格利资工.
曹德成：清华大学建.
李大明：英国WSP集.
李卫星：项目管理专.
王爱华：北京广联达.
何磊：神龙汽车有限.
陈虔：项目管理专家
曹济：项目管理专家
刘大双：项目管理软.
王树文：华南资讯科.
王守清：清华大学教.
吴之明：北京中科项.
卢毅访谈：合力金桥.
钱福培：国际项目管.
赵巍：神州数码中国.
王景山：制造业项目.
吴建中：西气东输工.
潘东：神州数码金融.
陈奕雍：游戏项目管.
刘景梅：朗讯公司项.
周小桥：项目管理专.
陈和兰：项目管理高.
黄绍良：项目管理专.
甄进明：项目管理专.
---请选择更多会员---
联盟会员专栏―路带一
联盟会员专栏―尹义法
联盟会员专栏―Lily
联盟会员专栏―马琛
联盟会员专栏―肖杨
联盟会员专栏―高国伟
联盟会员专栏―张鲁峰
联盟会员专栏―张为
联盟会员专栏―高屹
联盟会员专栏―车飞扬
联盟会员专栏―高茂源
联盟会员专栏―戚安邦
联盟会员专栏―宋学军
联盟会员专栏―张志坚
联盟会员专栏―杨铭伟
联盟会员专栏―杨立东
联盟会员专栏―曹济
联盟会员专栏―丁荣贵
联盟会员专栏―侯利军
联盟会员专栏―刘羚
联盟会员专栏―齐保良
联盟会员专栏―周炳学
联盟会员专栏―周劲松
联盟会员专栏―王凌宇
联盟会员专栏―蒋昕炜
联盟会员专栏―贾宗元
联盟会员专栏―张保军
联盟会员专栏―高扬
联盟会员专栏―司馥声
联盟会员专栏―郑德辉
联盟会员专栏―潘东
联盟会员专栏―冷力强
联盟会员专栏―潘德有
联盟会员专栏―蒋卫平
联盟会员专栏―王志远
联盟会员专栏―赵玫梅
联盟会员专栏―郭致星
联盟会员专栏―孙晓枚
联盟会员专栏―濮立松
联盟会员专栏―张雪峰
联盟会员专栏―张连永
联盟会员专栏―吴党明
联盟会员专栏―于学勇
联盟高级顾问―吴之明
联盟高级顾问―强茂山
联盟高级顾问―蔚林巍
联盟高级顾问―乔&&东
联盟高级顾问―杨光清
联盟高级顾问―黄绍良
联盟高级顾问―徐成彬
联盟高级顾问―熊培霖
联盟高级顾问―王景山
联盟高级顾问―陈和兰
联盟高级顾问―黄萌凌
联盟高级顾问―何&&丰
联盟高级顾问―刘大双
联盟高级顾问―袁月建
联盟高级顾问―郑文彬
联盟高级顾问―周小桥
联盟高级顾问―甄进明
联盟高级顾问―胡允清
联盟高级顾问―沈&&音
联盟高级顾问―许江林
联盟高级顾问―刘景梅
联盟高级顾问―卢&&毅
联盟高级顾问―石海东
联盟高级顾问―侯利军
联盟高级顾问―黄堰江
联盟高级顾问―周坤坪
联盟高级顾问―李子健
联盟高级顾问―徐&&非
联盟高级顾问―李大明
联盟高级顾问―马正肖
联盟高级顾问―郑承满
联盟高级顾问―孙爱军
联盟高级顾问―吴 超
联盟高级顾问―杜寿兴
联盟高级顾问―胡云峰
联盟顾问―人月神话
联盟高级顾问―王树文
联盟高级顾问―耿岚岚
联盟高级顾问―孙&&武
联盟高级顾问―赵春明
联盟高级顾问―商蓉蓉
联盟高级顾问―刘&&睿
联盟高级顾问―白思俊
联盟会员专栏―郭远刚
项目管理者联盟特刊
联盟特刊是对网站会员发行的内部刊物，刊物内容包括：案例及分析等，得到了会员好评。
电子期刊：
---请选择---
2017年01月
2016年11月
2016年09月
2016年07月
2016年05月
2016年03月
2016年01月
2015年11月
2015年09月
2015年07月
2015年05月
2015年03月
2015年01月
2014年08月
2014年06月
2014年04月
2014年01月
2013年12月
2010年10月
2010年09月
2010年08月
2010年07月
2010年06月
2010年05月
2010年04月
2010年03月
2010年02月
2010年01月
2009年12月
2009年11月
2009年10月
2009年09月
2009年08月
2009年07月
2009年06月
2009年02月
2009年01月
2008年12月
2008年11月
2008年10月
2008年09月
2008年08月
2008年07月
2008年06月
2008年05月
2008年04月
2008年03月
2008年02月
2008年01月
2007年12月
2007年11月
2007年10月
2007年09月
2007年08月
2007年07月
2007年06月
2007年05月
2007年04月
2007年03月
2007年02月
2007年01月
2006年12月
2006年11月
2006年10月
2006年09月
2006年08月
2006年07月
2006年06月
2006年05月
2006年04月
2006年03月
2006年02月
2006年01月
2005年12月
2005年11月
2005年10月
2005年09月
2005年08月
2005年07月
2005年06月
2005年05月
2005年04月
2005年03月
2005年02月
2004年11月
2004年10月
2004年09月
2004年08月
2004年07月
2004年06月
2004年05月
特刊下载：
---请选择---
<option value="http://www.mypm.net/resourcecenter/resource_content.asp?ID=-03月
<option value="http://www.mypm.net/resourcecenter/resource_content.asp?ID=-06月
<option value="http://www.mypm.net/resourcecenter/resource_content.asp?ID=-09月
<option value="http://www.mypm.net/resourcecenter/resource_content.asp?ID=-12月
<option value="http://www.mypm.net/resourcecenter/resource_content.asp?ID=-06月
<option value="http://www.mypm.net/resourcecenter/resource_content.asp?ID=-09月
<option value="http://www.mypm.net/resourcecenter/resource_content.asp?ID=-03月
<option value="http://www.mypm.net/resourcecenter/resource_content.asp?ID=-12月
<option value="http://www.mypm.net/resourcecenter/resource_content.asp?ID=-09月
<option value="/resourcecenter/resource_content.asp?ID=-06月
<option value="/resourcecenter/resource_content.asp?id=-03月
<option value="/resourcecenter/resource_content.asp?id=-12月
<option value="/resourcecenter/resource_content.asp?id=-09月
<option value="/resourcecenter/resource_content.asp?id=-06月
<option value="/resourcecenter/resource_content.asp?ID=-03月
06年10-12月
06年07-09月
<option value="/resourcecenter/resource_content.asp?ID=-06月
<option value="/resourcecenter/resource_content.asp?ID=-12月
<option value="/resourcecenter/resource_content.asp?ID=-7合集
施工企业管理
《施工企业管理》创刊于1986年1月，中国施工企业管理协会主办，是反映施工企业管理杂志。
浏览往期：
---请选择---
2013年04月刊
2011年10月刊
2011年09月刊
2011年08月刊
2011年07月刊
2011年06月刊
2011年05月刊
2011年04月刊
2011年03月刊
2011年02月刊
2011年01月刊
2010年12月刊
2010年11月刊
2010年10月刊
2010年09月刊
2010年08月刊
2010年07月刊
2010年06月刊
2010年05月刊
2010年04月刊
2010年03月刊
2010年02月刊
2010年01月刊
2009年12月刊
2009年11月刊
2009年10月刊
2009年09月刊
2009年08月刊
2009年07月刊
2009年06月刊
2009年05月刊
2009年04月刊
2009年03月刊
2009年02月刊
2009年01月刊
2008年12月刊
2008年11月刊
2008年10月刊
2008年09月刊
2008年08月刊
2008年07月刊
2008年06月刊
2008年05月刊
2008年04月刊
2008年03月刊
2008年02月刊
2008年01月刊
2007年12月刊
2007年11月刊
2007年10月刊
2007年09月刊
2007年08月刊
2007年07月刊
2007年06月刊
2007年05月刊
2007年04月刊
2007年03月刊
2007年02月刊
2007年01月刊
2006年12月刊
2006年11月刊
2006年10月刊
2006年09月刊
2006年08月刊
2006年07月刊
2006年06月刊
2006年05月刊
2006年04月刊
2006年03月刊
2006年02月刊
2006年01月刊
2005年12月刊
2005年11月刊
2005年10月刊
建造师杂志
《建造师》杂志由清华国际工程项目管理研究院主办，是中国面向建设企业管理人的高端杂志。
浏览往期：
---请选择---
2011年04月刊
2011年03月刊
2011年02月刊
2011年01月刊
2010年11月刊
2010年09月刊
2010年07月刊
2010年05月刊
2010年03月刊
2010年01月刊
2009年11月刊
2009年10月刊
2009年09月刊
2009年08月刊
2009年07月刊
2009年06月刊
2009年05月刊
2009年04月刊
2009年03月刊
2009年02月刊
2009年01月刊
2008年12月刊
2008年11月刊
2008年10月刊
2008年09月刊
2008年08月刊
2008年07月刊
2006年12月刊
2006年11月刊
2006年10月刊
2006年09月刊
2006年08月刊
2006年07月刊
2006年06月刊
08-10?08-10?08-10?08-10?08-07?08-07?08-07?08-07?08-04?08-04?08-04?08-04?08-04?07-10?07-10?07-10?
项目管理者联盟 版权所有 京ICP证070584号 | 京公网安备号
如转载本站文章，必须于文章开头处注明转自“项目管理者联盟”，并注明原作者下次自动登录
现在的位置:
& 综合 & 正文
需求分析的重要性以及如何做好需求分析
需求分析的重要性以及如何做好需求分析
为什么以这个为主题写.是因为最近在做一个购物网,需求没有做好,导致做前台的时候商品与图片是1对1的关系,后台添加的时候有很大的弊端.和漏洞不好弥补.不是不好弥补.是牵扯的逻辑太多.如果说改了这个网站可以重做了.所以说很失败.
如果因为一个地方的失误.很可能导致整个项目的失败.那么你最近的所有努力将灰飞烟灭...
那么,如果在项目开始前做好充分的需求.而且需求要做的到位,需求的思维严谨程度至关重要..
一. 为什么要需求分析
需求分析就是分析软件用户的需求是什么.如果投入大量的人力，物力,财力,时间,开发出的软件却没人要,那所有的投入都是徒劳.如果费了很大的精力,开发一个软件,最后却不满足用户的要求,从而要重新开发过,这种返工是让人痛心疾首的.(相信大家都有体会)比如,用户需要一个for linux的软件,而你在软件开发前期忽略了软件的运行环境,忘了向用户询问这个问题,而想当然的认为是开发for windows的软件,当你千辛万苦地开发完成向用户提交时才发现出了问题,那时候你是欲哭无泪了,痕不得找块豆腐一头撞死.
(这个问题是最典型也是最常见的,现在这个问题一般很好避免,都知道项目的一些敏感性的东西,例如想会有哪些地方设计的不好可能导致以后的使用出现BUG.)
二. 需求分析的任务
简言之,需求分析的任务就是解决"做什么"的问题,就是要全面地理解用户的各项要求,并准确地表达所接受的用户需求.
三. 需求分析的过程
需求分析阶段的工作,可以分为四个方面:问题识别,分析与综合,制订规格说明,评审.
(1) 问题识别
就是从系统角度来理解软件,确定对所开发系统的综合要求,并提出这些需求的实现条件,以及需求应该达到的标准.这些需求包括：功能需求(做什么),性能需求(要达到什么指标),环境需求(如机型,操作系统等),可靠性需求(不发生故障的概率）,安全保密需求,用户界面需求,资源使用需求(软件运行是所需的内存,CPU等),软件成本消耗与开发进度需求,预先估计以后系统可能达到的目标.
(2) 分析与综合
逐步细化所有的软件功能,找出系统各元素间的联系,接口特性和设计上的限制,分析他们是否满足需求,剔除不合理部分,增加需要部分.最后,综合成系统的解决方案,给出要开发的系统的详细逻辑模型(做什么的模型).
(3) 制订规格说明书
即编制文档,描述需求的文档称为软件需求规格说明书.请注意,需求分析阶段的成果是需求规格说明书(好象软考曾经考过这个问题),向下一阶段提交.
对功能的正确性,完整性和清晰性,以及其它需求给予评价.评审通过才可进行下一阶段的工作,否则重新进行需求分析。
四. 需求分析的方法
需求分析的方法有很多.这里只强调原型化方法,其它的方法如:结构化方法,动态分析法等(个人认为,对初学者不必深究这些方法,实际上我也从来没用过这些方法)在此不讨论.
原型化方法是十分重要的(是软考等常考的知识点).原型就是软件的一个早期可运行的版本,它实现了目标系统的某些或全部功能.
原型化方法就是尽可能快地建造一个粗糙的系统,这系统实现了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷.建造这样一个系统的目的是为了考察某一方面的可行性,如的可行性,技术的可行性,或考察是否满足用户的需求等.如,为了考察是否满足用户的要求,可以用某些软件工具快速的建造一个原型系统,这个系统只是一个界面,然后听取用户的意见,改进这个原型.以后的目标系统就在原型系统的基础上开发.
原型主要有三种类型(软考考过):探索型,实验型,进化型.探索型:目的是要弄清楚对目标系统的要求,确定所希望的特性,并探讨多种方案的可行性.实验型:用于大规模开发和实现前,考核方案是否合适,规格说明是否可靠.进化型:目的不在于改进规格说明,而是将系统建造得易于变化,在改进原型的过程中,逐步将原型进化成最终系统。
在使用原型化方法是有两种不同的策略:废弃策略,追加策略.废弃策略:先建造一个功能简单而且质量要求不高的模型系统，针对这个系统反复进行修改,形成比较好的思想,据此设计出较完整,准确,一致,可靠的最终系统.系统构造完成后,原来的模型系统就被废弃不用.探索型和实验型属于这种策略。
追加策略:先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心,然后通过不断地扩充修改,逐步追加新要求，发展成为最终系统。进化型属于这种策略.
五. 需求分析的20条法则（本节摘自软件工程专家网）
客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。
1. 分析人员要使用符合客户语言习惯的表达 　　
需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。
2. 分析人员要了解客户的业务及目标 　　
只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。
3. 分析人员必须编写软件需求报告 　　
分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。
4. 要求得到需求工作结果的解释说明 　　
分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。
5. 开发人员要尊重客户的意见 　
如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。
6. 开发人员要对需求及产品实施提出建议和解决方案 　　
通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。
7. 描述产品使用特性 　　
客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。
8. 许重用已有的软件组件 　　
需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。
9. 要求对变更的代价提供真实可靠的评估 　　
有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。
10. 获得满足客户功能和质量要求的系统 　　
每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。
11. 给分析人员讲解您的业务 　　
分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。
12. 抽出时间清楚地说明并完善需求 　　
客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。
13. 准确而详细地说明需求 　　
编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。
在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。
14. 及时作出决定 　　
分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。
15. 尊重开发人员的需求可行性及成本评估 　　
所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。
16. 划分需求的优先级 　　
绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。　　在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。
17. 评审需求文档和原型
客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。
18. 需求变更要立即联系
不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。
19. 遵照开发小组处理需求变更的过程 　　
为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。
20. 尊重开发人员采用的需求分析过程 　　
软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。
“需求确认”意味着什么 　　
在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。” 　　
这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。” 　　
同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。” 　　
这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。
对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。
　　需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。
六. 点评需求分析误区
要想说什么是好的需求分析，不如说什么是不好的需求分析，知道什么是不好的，自然也就知道了什么是好的。以下就是一些不好的情况：
(1) 创意和求实
毋庸质疑的，每个人都会为自己的一个新的Ｉｄｅａ而激动万分，特别是当这个Ｉｄｅａ受到一些根本不知道你原本要干嘛的人的惊赞时。但是请注意，当你激动得意的时候，你可能已经忘了你原本是在描述一个需求，而不是在策划一个创意、创造一个概念。很多刚开始做需求分析的人员都或多或少的会犯这样的错误，陶醉在自己的新想法和新思路中，却违背了需求的原始客观性和真实性原则。
永远别忘了：需求不是空中楼阁，是实实在在的一砖一瓦。
(2) 解剖的快感
几乎所有搞软件的人，做需求分析的时候，一上来就会把用户告诉你的要求，完完整整的作个解剖，切开分成几个块，再细分成几个子块，然后再条分缕析。可是当用户迷惑的看着你辛辛苦苦做出来的分析结果问你：我想作一个数据备份的任务，怎么做？这时，你会发现，需要先后打开三个窗口才能完成这个任务。
永远别忘了：分解是必需的，但最终的目的是为了更好的组合，而不是为了分解。
(3) 角度和思维
经常听到这样的抱怨：“用户怎么可以提出这样苛刻的要求呢？”。细细一了解，你会发现，用户只不过是要求把一个需要两次点击的功能，改成只有一次点击。这样会导致需要改变需求、改变编码、甚至重新测试，增加工作量。可是，如果换个角度来想想，这个功能，开发的时候只用了几次、几十次，可是用户每天都要用几百次甚至几千次几万次，改动一下就减少了一半的工作量，对他来说，这样的需求难道会苛刻吗？
永远别忘了：没有任何需求是不对的，不对的只是你的需求分析。试着站在用户的思维角度想想，你的需求分析就会更加的贴近用户，更加的合理。软件应该是以人为本的。
(4) 程序员逻辑
从程序员成长为系统分析员是一个普遍的轨迹，但并不是一个好的程序员就必然能成为一个好的系统分析员。一些程序员的固化逻辑，使得他们在做需求分析的时候往往钻进了一些牛角里面。比如说１／０逻辑（或者是说黑白逻辑），认为不是这样就是那样，没有第三种情况。可实际情况往往是，在一定的时候是这样，其它时候是那样。又比如穷举逻辑，喜欢上来就把所有一二三可能的情况列举出来，然后一个一个分别处理，每个占用三分之一的时间；可是实际的情况往往是，三分之一的情况占了９９％的比例，其它两种情况一年都不会遇到一次。实际中还有很多这样的例子，不一一列举了。
永远别忘了：需求分析和程序设计不尽相同，合理、可行是才是重要的。跳出程序设计的圈子，站在系统的角度上来看问题，你的结论会截然不同。
&&&&推荐文章:
【上篇】【下篇】