2011-1-6作者:谢添来源:似水流年
对商业用户来说,他们后面是成百上千个供应商,前面是成千上万个消费顾客。怎样利用软件管理错综复杂的供应商和消费顾客,如何做好精细到一个小小调料包的进、销、调、存的商品流通工作,这些都是商业企业需要信息管理系统的理由。软件开发的意义也就在于此。而弄清商业用户如此复杂需求的真面目,正是软件开发成功的关键所在。
经理:“我们要建立一套完整的商业管理软件系统,包括商品的进、销、调、存管理,是总部-门店的连锁经营模式。通过通信手段门店自动订货,供应商自动结算,卖场通过扫条码实现销售,管理人员能够随时查询门店商品销售和库存情况。另外,我们也得为政府部门提供关于商品营运的报告。”
分析员:“我已经明白这个项目的大体结构框架,这非常重要,但在制定计划之前,我们必须收集一些需求。”
经理觉得奇怪:“我不是刚告诉你我的需求了吗?”
分析员:“实际上,您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论,然后才能真正明白达到业务目标所需功能和用户要求,了解清楚后,才可以发现哪些是现有组件即可实现的,哪些是需要开发的,这样可节省很多时间。”
经理:“业务人员都在招商。他们非常忙,没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统?”
分析员尽量解释从用户处收集需求的合理性:“如果我们只是凭空猜想用户的要求,结果不会令人满意。我们只是软件开发人员,而不是采购专家、营运专家或是财务专家,我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过,未真正明白这些问题就开始编码,结果没有人对产品满意。”
经理坚持道:“行了,行了,我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发,并随时将你们的进展情况告诉我。”
客户与开发人员交流需要好的方法。下面建议20条法则,客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧,将通过协商达成对各自义务的相互理解,以便减少以后的磨擦(如一方要求而另一方不愿意或不能够满足要求)。
1、分析人员要使用符合客户语言习惯的表达
需求讨论集中于业务需求和任务,因此要使用术语。客户应将有关术语(例如:采价、印花商品等采购术语)教给分析人员,而客户不一定要懂得计算机行业的术语。
2、分析人员要了解客户的业务及目标
只有分析人员更好地了解客户的业务,才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员,客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统,那么开发和分析人员应使用一下目前的旧系统,有利于他们明白目前系统是怎样工作的,其流程情况以及可供改进之处。
3、分析人员必须编写软件需求报告
分析人员应将从客户那里获得的所有信息进行整理,以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析,客户就能得到一份“需求分析报告”,此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告,以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。
4、要求得到需求工作结果的解释说明
分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明,因为工作图表能很清晰地描述出系统行为的某些方面,所以报告中各种图表有着极高的价值;虽然它们不太难于理解,但是客户可能对此并不熟悉,因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果,以及怎样检查图表有无错误及不一致等。
5、开发人员要尊重客户的意见
如果用户与开发人员之间不能相互理解,那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间,同样,客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。
6、开发人员要对需求及产品实施提出建议和解决方案
通常客户所说的“需求”已经是一种实际可行的实施方案,分析人员应尽力从这些解决方法中了解真正的业务需求,同时还应找出已有系统与当前业务不符之处,以确保产品不会无效或低效;在彻底弄清业务领域内的事情后,分析人员就能提出相当好的改进方法,有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。
7、描述产品使用特性
客户可以要求分析人员在实现功能需求的同时还注意软件的易用性,因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如:客户有时要求产品要“界面友好”或“健壮”或“高效率”,但对于开发人员来讲,太主观了并无实用价值。正确的做法是,分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性,具体分析哪些特性对哪些特性有负面影响,在性能代价和所提出解决方案的预期利益之间做出权衡,以确保做出合理的取舍。
8、允许重用已有的软件组件
需求通常有一定灵活性,分析人员可能发现已有的某个软件组件与客户描述的需求很相符,在这种情况下,分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间,而不必严格按原有的需求说明开发。所以说,如果想在产品中使用一些已有的商业常用组件,而它们并不完全适合您所需的特性,这时一定程度上的需求灵活性就显得极为重要了。
9、要求对变更的代价提供真实可靠的评估
有时,人们面临更好、也更昂贵的方案时,会做出不同的选择。而这时,对需求变更的影响进行评估从而对业务决策提供帮助,是十分必要的。所以,客户有权利要求开发人员通过分析给出一个真实可信的评估,包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。
10、获得满足客户功能和质量要求的系统
每个人都希望项目成功,但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息,而且还要求开发人员能通过交流了解清楚取舍与限制,一定要明确说明您的假设和潜在的期望,否则,开发人员开发出的产品很可能无法让您满意。
11、给分析人员讲解您的业务
分析人员要依靠客户讲解业务概念及术语,但客户不能指望分析人员会成为该领域的专家,而只能让他们明白您的问题和目标;不要期望分析人员能把握客户业务的细微潜在之处,他们可能不知道那些对于客户来说理所当然的“常识”。
12、抽出时间清楚地说明并完善需求
客户很忙,但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论,接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点,而过后发现还需要您的讲解,这时请耐心对待一些需求和需求的精化工作过程中的反复,因为它是人们交流中很自然的现象,何况这对软件产品的成功极为重要。
13、准确而详细地说明需求
编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时,因此很容易留下模糊不清的需求。但是在开发过程中,必须解决这种模糊性和不准确性,而客户恰恰是为解决这些问题作出决定的最佳人选,否则,就只好靠开发人员去正确猜测了。
在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方,有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚,以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达,通常就要求用原型技术,通过原型开发,客户可以同开发人员一起反复修改,不断完善需求定义。
14、及时作出决定
分析人员会要求客户作出一些选择和决定,这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切,尽快做处理,做决定,因为开发人员通常只有等客户做出决定才能行动,而这种等待会延误项目的进展。
15、尊重开发人员的需求可行性及成本评估
所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通,或者实现它要付出极高的代价,而某些需求试图达到在操作环境中不可能达到的性能,或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价,客户应该尊重他们的意见。
16、划分需求的优先级
绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的,哪些是重要的,是需求开发的主要部分,这只能由客户负责设定需求优先级,因为开发者不可能按照客户的观点决定需求优先级;开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。
在时间和资源限制下,关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现,但毕竟是要面对现实,业务决策有时不得不依据优先级来缩小项目范围或延长工期,或增加资源,或在质量上寻找折衷。
17、评审需求文档和原型
客户评审需求文档,是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确,就有必要尽早告知分析人员并为改进提供建议。
更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员,使他们更好地理解您的需求;原型并非是一个实际应用产品,但开发人员能将其转化、扩充成功能齐全的系统。
18、需求变更要立即联系
不断的需求变更,会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的,但在开发周期中,变更越在晚期出现,其影响越大;变更不仅会导致代价极高的返工,而且工期将被延误,特别是在大体结构已完成后又需要增加新特性时。所以,一旦客户发现需要变更需求时,请立即通知分析人员。
19、遵照开发小组处理需求变更的过程
为将变更带来的负面影响减少到最低限度,所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更,对每项要求的变更进行分析、综合考虑,最后做出合适的决策,以确定应将哪些变更引入项目中。
20、尊重开发人员采用的需求分析过程
软件开发中最具挑战性的莫过于收集需求并确定其正确性,分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算,但请相信花在需求开发上的时间是非常有价值的;如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术,那么整个过程将会更为顺利。
分享到:
相关推荐
需求分析中减少客户摩擦的20大法则.docx
针对国内外有关结构面基本摩擦角、残余摩擦角的研究,对数据进行统计分析和对比。结果表明:基本摩擦角集中在20°~35°,残余摩擦角集中在25°~50°。对大多数岩石来说,残余摩擦角大于基本摩擦角;岩体结构面基本摩擦角...
本案例属于热-结构耦合场分析问题,也属于旋转摩擦生热问题,选用耦合场三维六面体二十节点SOLID226单元进行分析,将角速度转换为切向位移载荷施加在铜块上。
在端面滚柱包络环面蜗杆传动啮合理论和摩檫学的基础上,建立了端面滚柱蜗轮滚动系数摩擦模型,分析了啮合传动过程中摩擦系数的变化规律。在此基础上,运用MATLAB软件进行数值仿真,得出端面滚柱蜗轮传动在啮合周期内摩擦...
在滑坡过程中,其动力学机制对于理解和预测这类自然灾害非常重要。 本文提出了一种基于复杂网络概念的新方法,以研究边坡滑动过程中中尺度接触... 4)随着颗粒间摩擦系数的增加,3循环次数增加,4循环和5循环次数减少。
刚柔耦合干摩擦系统振动分析,丁千,赵旖旎,本文针对制动摩擦颤振现象,建立了盘式制动装置的刚柔耦合动力学模型,应用伽辽金离散和数值计算,揭示了摩擦块的盘面振动与摩擦
利用UG三维建模软件对JKM-2.8×6(I)A型多绳摩擦式提升机摩擦轮进行三维建模,并将模型导入ANSYS有限元分析软件中。基于工况数据监测平台的数据,对摩擦轮进行不同工况下的加载和约束,然后进行有限元受力分析,得到各...
对304L不锈钢板进行摩擦搅拌焊分析,求解应力结果。
workbench摩擦生热案例。在一个定块上,有一个滑块。在滑块顶顶面上施加一垂直于表面指向定块的10MPa的分布力系。现在滑块在定块表面上滑行3.75mm,要求摩擦而产生的热量,并计算滑块和定块内部的温度分布和应力分布...
断层面摩擦强度是评价煤炭开采中应力扰动诱发断层滑动危险性的依据。依托晋城矿区成庄井田,采用理论分析和数值模拟计算方法,分析了断层面摩擦强度对深部地应力的约束机制,研究了成庄井田F13断层及其在不同摩擦强度...
机构力分析机械原理作图法考虑摩擦力Matlab程序分享-机构力分析(考虑摩擦力).zip 本帖最后由 chanceller ...使用Matlab成功编写了动态演示的机械原理中考虑摩擦力机构力分析动画。 效果还不错,大家雅俗共享。:)
2021年最新初中物理摩擦力教案 初中物理摩擦力教材分析
弹塑性摩擦接触的热力耦合分析,吴爱中,,针对固体材料之间摩擦滑移过程中的热力耦合问题,建立了一个温度-应力实时耦合的弹塑性接触模型,在此基础上,采用有限元方法分�
球轴承摩擦力矩的分析计算_张葵.pdf
创业需谨慎:减少摩擦 打造快乐体验.docx
平板型水润滑橡胶轴承摩擦噪声的有限元分析,周忆,张恒,利用ABAQUS软件建立了平板型水润滑轴承的摩擦噪声分析模型,采用复模态理论,依据复特征值实部的正负判断轴承系统发生噪声的可能性
行业分类-设备装置-有减少摩擦涂层的纸板容器.zip
仿生摩擦学在圆柱摩擦轮传动中的应用,黄维刚,高朋朋,在传动比要求不是特别精确的情况下,圆柱摩擦轮传动结构有着广泛的应用。摩擦轮传动中,为了增大摩擦驱动力,要求摩擦轮之间压紧�
基于ABAQUS的固体润滑摩擦副接触问题分析,刘朋威,周忆,针对固体润滑滚动轴承的使用条件和接触特点,建立了固体润滑摩擦副的接触模型,利用有限元方法分析了模型在不同摩擦系数下的VonMis
行业-电子政务-减少静摩擦和钝化微电机表面的晶片水平处理方法及其所用化合物.zip