需求的重要性.docx
《需求的重要性.docx》由会员分享，可在线阅读，更多相关《需求的重要性.docx（28页珍藏版）》请在冰豆网上搜索。
需求的重要性
求分析的重要性以及如何做好需求分析
[
转
]
收藏
文章出处：
为什么以这个为主题写
.
是因为最近在做一个购物网
需求没有做好
导致做前台的时候
商品与图片是
1
对
1
的关系
后台添加的时候有很大的弊端
.
和漏洞不好弥补
.
不是不好弥补
.
是牵扯的逻辑太多
.
如果说改了这个网站可以重做了
.
所以说很失败
.
如果因为一个地方的失误
.
很可能导致整个项目的失败
.
那么你最近的所有努力将灰飞烟
灭
...
那么
如果在项目开始前做好充分的需求
.
而且需求要做的到位
需求的思维严禁程度至
关重要
..
（
下面为转载
）
一、为什么要需求分析
需求分析就是分析软件用户的需求是什么
.
如果投入大量的人力，力,财力,时间开发出的软件却没人要那所有的投入都是徒劳，如果费了很大的精力，开发一个软件最后却不满足用户的要求
从而要重新开发过这种返工是让人痛心疾首的.（相信大家都有体会）比：
用户需要一个for linux的软件而你在软件开发前期忽略了软件的运行环境忘了向用户询问这个问题而想当然的认为是开发for windows的软件当你千辛万苦地开发完成向用户提交时才发现出了问题那时候你是欲哭无泪了痕不得找块豆腐一头撞死这个问题是最典型也是最常见的现在这个问题一般很好避免都知道项目的一些敏感性的东西
例如想会有哪些地方设计的不好可能导致以后的使用出现
BUG）
二、需求分析的任务
简言之
需求分析的任务就是解决
"
做什么
"
的问题
就是要全面地理解用户的各项要求
并准确地表达所接受的用户需求
三、需求分析的过程
需求分析阶段的工作
可以分为四个方面
:
问题识别
分析与综合
制订规格说明
评审
.
问题识别
就是从系统角度来理解软件
确定对所开发系统的综合要求
并提出这些需求的实现条
件
以及需求应该达到的标准
.
这些需求包括：
功能需求
（
做什么
）,
性能需求
（
要达到什么指标
）,
环境需求
（
如机型
操作系统等
）,
可靠性需求
（
不发生故障的概率）
安全保密需求
用户界面需求
资源使用需求
（
软件运行是所需的内存
CPU
等
）,
软件成本消耗与开发进度需求
预先估计以后
系统可能达到的目标
.
分析与综合
逐步细化所有的软件功能
找出系统各元素间的联系
接口特性和设计上的限制
分析
他们是否满足需求
剔除不合理部分
增加需要部分
.
最后
综合成系统的解决方案
给出要开发
的系统的详细逻辑模型
（
做什么的模型
）.
制订规格说明书
即编制文档
描述需求的文档称为软件需求规格说明书
.
请注意
需求分析阶段的成果
是需求规格说明书
（
好象软考曾经考过这个问题
）,
向下一阶段提交
评审
对功能的正确性
完整性和清晰性
以及其它需求给予评价
.
评审通过才可进行下一阶
段的工作
否则重新进行需求分析。
四、需求分析的方法
需求分析的方法有很多
.
这里只强调原型化方法
其它的方法如：
结构化方法、动态分析法等（个人认为对初学者不必深究这些方法实际上我也从来没用过这些方法）在此不讨论原型化方法是十分重要的（是软考等常考的知识点）.原型就是软件的一个早期可运行的版本它实现了目标系统的某些或全部功能原型化方法就是尽可能快地建造一个粗糙的系统了目标系统的某些或全部功能,但是这个系统可能在可靠性,界面的友好性或其他方面上存在缺陷建造这样一个系统的目的是为了考察某一方面的可行性如算法的可行性,
技术的可行,
或考察是否满足用
户的需求等如：
为了考察是否满足用户的要求
可以用某些软件工具快速的建造一个原型系
统
这个系统只是一个界面
然后听取用户的意见
改进这个原型
.
以后的目标系统就在原型系
统的基础上开发
原型主要有三种类型
（
软考考过
）:
探索型
实验型
进化型
.
探索型
:
目的是要弄清楚对目
标系统的要求
确定所希望的特性
并探讨多种方案的可行性
.
实验型
:
用于大规模开发和实现
前
考核方案是否合适
规格说明是否可靠
.
进化型
:
目的不在于改进规格说明
而是将系统建造
得易于变化
在改进原型的过程中
逐步将原型进化成最终系统。
在使用原型化方法是有两种不同的策略
:
废弃策略
追加策略
.
废弃策略
:
先建造一个功
能简单而且质量要求不高的模型系统，针对这个系统反复进行修改
形成比较好的思想
据此
设计出较完整
准确
一致
可靠的最终系统
.
系统构造完成后
原来的模型系统就被废弃不用
.
探
索型和实验型属于这种策略。
追加策略
:
先构造一个功能简单而且质量要求不高的模型系统，作为最终系统的核心
然后通过不断地扩充修改
逐步追加新要求，发展成为最终系统。
进化型属于这种策略
五、需求分析的
20
条法则（本节摘自软件工程专家网）
客户与开发人员交流需要好的方法。
下面建议
20
条法则，客户和开发人员可以通过
评审以下内容并达成共识。
如果遇到分歧，
将通过协商达成对各自义务的相互理解，
以便减
少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。
1、分析人员要使用符合客户语言习惯的表达
需求讨论集中于业务需求和任务，
因此要使用术语。
客户应将有关术语
（例如：
采价、
印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。
2、分析人员要了解客户的业务及目标
只有分析人员更好地了解客户的业务，
才能使产品更好地满足需要。
这将有助于开发
人员设计出真正满足客户需要并达到期望的优秀软件。
为帮助开发和分析人员，
客户可以考
虑邀请他们观察自己的工作流程。
如果是切换新系统，
那么开发和分析人员应使用一下目前
的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。
3、分析人员必须编写软件需求报告
分析人员应将从客户那里获得的所有信息进行整理，
以区分业务需求及规范、
功能需
求、质量目标、解决方法和其他信息。
通过这些分析，客户就能得到一份“需求分析报告”
，
此份报告使开发人员和客户之间针对要开发的产品内容达成协议。
报告应以一种客户认为易
于翻阅和理解的方式组织编写。
客户要评审此报告，
以确保报告内容准确完整地表达其需求。
一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。
4、要求得到需求工作结果的解释说明
分析人员可能采用了多种图表作为文字性
“需求分析报告”
的补充说明，
因为工作图
表能很清晰地描述出系统行为的某些方面，
所以报告中各种图表有着极高的价值；
虽然它们
不太难于理解，
但是客户可能对此并不熟悉，
因此客户可以要求分析人员解释说明每个图表
的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。
5、开发人员要尊重客户的意见
如果用户与开发人员之间不能相互理解，
那关于需求的讨论将会有障碍。
共同合作能
使大家“兼听则明”
。
参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项
目成功所付出的时间，
同样，
客户也应对开发人员为项目成功这一共同目标所做出的努力表
示尊重。
6、开发人员要对需求及产品实施提出建议和解决方案
通常客户所说的
“需求”
已经是一种实际可行的实施方案，
分析人员应尽力从这些解
决方法中了解真正的业务需求，
同时还应找出已有系统与当前业务不符之处，
以确保产品不
会无效或低效；
在彻底弄清业务领域内的事情后，
分析人员就能提出相当好的改进方法，
有
经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。
7、描述产品使用特性
客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，
因为这些易用特
性或质量属性能使客户更准确、高效地完成任务。
例如：
客户有时要求产品要“界面友好”
或“健壮”或“高效率”
，但对于开发人员来讲，太主观了并无实用价值。
正确的做法是，
分析人员通过询问和调查了解客户所要的
“友好、
健壮、
高效所包含的具体特性，
具体分析
哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，
以确保做出合理的取舍。
8
、
允许重用已有的软件组件
需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求
很相符，
在这种情况下，
分析人员应提供一些修改需求的选择以便开发人员能够降低新系统
的开发成本和节省时间，
而不必严格按原有的需求说明开发。
所以说，
如果想在产品中使用
一些已有的商业常用组件，
而它们并不完全适合您所需的特性，
这时一定程度上的需求灵活
性就显得极为重要了。
9
、
要求对变更的代价提供真实可靠的评估
有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。
而这时，对需求变
更的影响进行评估从而对业务决策提供帮助，
是十分必要的。
所以，
客户有权利要求开发人
员通过分析给出一个真实可信的评估，
包括影响、
成本和得失等。
开发人员不能由于不想实
施变更而随意夸大评估成本。
10
、
获得满足客户功能和质量要求的系统
每个人都希望项目成功，
但这不仅要求客户要清晰地告知开发人员关于系统
“做什么”
所需的所有信息，
而且还要求开发人员能通过交流了解清楚取舍与限制，
一定要明确说明您
的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。
11
、
给分析人员讲解您的业务
分析人员要依靠客户讲解业务概念及术语，
但客户不能指望分析人员会成为该领域的
专家，
而只能让他们明白您的问题和目标；
不要期望分析人员能把握客户业务的细微潜在之
处，他们可能不知道那些对于客户来说理所当然的“常识”
。
12
、
抽出时间清楚地说明并完善需求
客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，
接受采访
或其他获取需求的活动。
有些分析人员可能先明白了您的观点，
而过后发现还需要您的讲解，
这时请耐心对待一些需求和需求的精化工作过程中的反复，
因为它是人们交流中很自然的现
象，何况这对软件产品的成功极为重要。
13
、
准确而详细地说明需求
编写一份清晰、准确的需求文档是很困难的。
由于处理细节问题不但烦人而且耗时，
因此很容易留下模糊不清的需求。
但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。
在需求分析中暂时加上“待定”标志是个方法。
用该标志可指明哪些是需要进一步讨
论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”
。
客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们
写进“软件需求报告”中去。
如果客户一时不能准确表达，通常就要求用原型技术，通过原
型开发，客户可以同开发人员一起反复修改，不断完善需求定义。
14、 及时作出决定
分析人员会要求客户作出一些选择和决定，
这些决定包括来自多个用户提出的处理方
法或在质量特性冲突和信息准确度中选择折衷方案等。
有权作出决定的客户必须积极地对待
这一切，尽快做处理，做决定，
因为开发人员通常只有等客户做出决定才能行动，
而这种等
待会延误项目的进展。
15
、
尊重开发人员的需求可行性及成本评估
所有的软件功能都有其成本。
客户所希望的某些产品特性可能在技术上行不通，
或者
实现它要付出极高的代价，
而某些需求试图达到在操作环境中不可能达到的性能，
或试图得
到一些根本得不到的数据。
开发人员会对此作出负面的评价，客户应该尊重他们的意见。
16
、
划分需求的优先级
绝大多数项目没有足够的时间或资源实现功能性的每个细节。
决定哪些特性是必要
的，哪些是重要的，
是需求开发的主要部分，
这只能由客户负责设定需求优先级，
因为开发
者不可能按照客户的观点决定需求优先级；
开发人员将为您确定优先级提供有关每个需求的
花费和风险的信息。
在时间和资源限制下，关于所需特性能否完成或完成多少应尊重
开发人员的意见。
尽管没有人愿意看到自己所希望的需求在项目中未被实现，
但毕竟是要面
对现实，
业务决策有时不得不依据优先级来缩小项目范围或延长工期，
或增加资源，
或在质
量上寻找折衷。
17
、
评审需求文档和原型
客户评审需求文档，
是给分析人员带来反馈信息的一个机会。
如果客户认为编写的
“需
求分析报告”
不够准确，
就有必要尽早告知分析人员并为改进提供建议。
更好的办法是先为
产品开发一个原型。
这样客户就能提供更有价值的反馈信息给开发人员，
使他们更好地理解
您的需求；
原型并非是一个实际应用产品，
但开发人员能将其转化、
扩充成功能齐全的系统。
18
、
需求变更要立即联系
不断的需求变更，
会给在预定计划内完成的质量产品带来严重的不利影响。
变更是不
可避免的，
但在开发周期中，变更越在晚期出现，
其影响越大；变更不仅会导致代价极高的
返工，
而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。
所以，一旦客
户发现需要变更需求时，请立即通知分析人员。
19
、
遵照开发小组处理需求变更的过程
为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。
这要求不放弃所有提出的变更，
对每项要求的变更进行分析、
综合考虑，
最后做出合适的决
策，以确定应将哪些变更引入项目中。
20
、
尊重开发人员采用的需求分析过程
软件开发中最具挑战性的莫过于收集需求并确定其正确性，
分析人员采用的方法有其
合理性。
也许客户认为收集需求的过程不太划算，
但请相信花在需求开发上的时间是非常有
价值的；
如果您理解并支持分析人员为收集、
编写需求文档和确保其质量所采用的技术，
那
么整个过程将会更为顺利。
“需求确认”意味着什么
出师表
两汉：
诸葛亮
先帝创业未半而中道崩殂，今天下三分，益州疲弊，此诚危急存亡之秋也。
然侍卫之臣不懈于内，忠志之士忘身于外者，盖追先帝之殊遇，欲报之于陛下也。
诚宜开张圣听，以光先帝遗德，恢弘志士之气，不宜妄自菲薄，引喻失义，以塞忠谏之路也。
宫中府中，俱为一体；陟罚臧否，不宜异同。
若有作奸犯科及为忠善者，宜付有司论其刑赏，以昭陛下平明之理；不宜偏私，使内外异法也。
侍中、侍郎郭攸之、费祎、董允等，此皆良实，志虑忠纯，是以先帝简拔以遗陛下：
愚以为宫中之事，事无大小，悉以咨之，然后施行，必能裨补阙漏，有所广益。
将军向宠，性行淑均，晓畅军事，试用于昔日，先帝称之曰“能”，是以众议举宠为督：
愚以为营中之事，悉以咨之，必能使行阵和睦，优劣得所。
亲贤臣，远小人，此先汉所以兴隆也；亲小人，远贤臣，此后汉所以倾颓也。
先帝在时，每与臣论此事，未尝不叹息痛恨于桓、灵也。
侍中、尚书、长史、参军，此悉贞良死节之臣，愿陛下亲之、信之，则汉室之隆，可计日而待也
。
臣本布衣，躬耕于南阳，苟全性命于乱世，不求闻达于诸侯。
先帝不以臣卑鄙，猥自枉屈，三顾臣于草庐之中，咨臣以当世之事，由是感激，遂许先帝以驱驰。
后值倾覆，受任于败军之际，奉命于危难之间，尔来二十有一年矣。
先帝知臣谨慎，故临崩寄臣以大事也。
受命以来，夙夜忧叹，恐托付不效，以伤先帝之明；故五月渡泸，深入不毛。
今南方已定，兵甲已足，当奖率三军，北定中原，庶竭驽钝，攘除奸凶，兴复汉室，还于旧都。
此臣所以报先帝而忠陛下之职分也。
至于斟酌损益，进尽忠言，则攸之、祎、允之任也。
愿陛下托臣以讨贼兴复之效，不效，则治臣之罪，以告先帝之灵。
若无兴德之言，则责攸之、祎、允等之慢，以彰其咎；陛下亦宜自谋，以咨诹善道，察纳雅言，深追先帝遗诏。
臣不胜受恩感激。
今当远离，临表涕零，不知所言。
升级会员 