[济南软件开发专题]软件开发需求分析法则

2014-05-05 08:52:05      访问:

【内容导读】 软件开发客户与开发人员交流需要好的方法。下面建议20条法令,客户和开发人员可以通过评审以下内容并达成共鸣。如果碰到不合,将通过协商达成对各自任务的互相理解,以便减少当前的磨擦(如一方要求而另一方不违心或不可以满意要求)。

软件开发过程中客户与开发人员交流需要好的方法。下面建议20条法令,客户和开发人员可以通过评审以下内容并达成共鸣。如果碰到不合,将通过协商达成对各自任务的互相理解,以便减少当前的磨擦(如一方要求而另一方不违心或不可以满意要求)。

1、分析人员要使用合乎客户语言习惯的表达

需求讨论集中于业务需求和任务,因此要使用术语。客户应将有关术语(例如:采价、印花商品等洽购术语)教给分析人员,而客户不一定要理解盘算机行业的术语。

2、分析人员要了解客户的业务及目的

只有分析人员更好地了解客户的业务,才干使产品更好地满意需要。这将有助于开发人员设计出真正知足客户须要并达到冀望的优良软件。为辅助开发和分析人员,客户可以斟酌邀请他们察看本人的工作流程。如果是切换新系统,那么开发和分析人员应使用一下目前的旧系统,有利于他们清楚目前系统是怎样工作的,其流程情况以及可供改进之处。

3、分析人员必须编写软件需求报告

分析人员应将从客户那里取得的所有信息进行收拾,以辨别业务需求及标准、功能需求、质量目标、解决方法和其他信息。通过这些分析,客户就能得到一份“需求分析报告”,此份报告使开发人员和客户之间针对要开发的产品内容达成协定。报告应以一种客户认为易于翻阅和理解的方法组织编写。客户要评审此报告,以确保报告内容准确完全地抒发其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。

4、要求得到需求工作结果的解释说明

分析人员可能采取了多种图表作为文字性“需求分析报告”的弥补解释,由于工作图表能很清晰地描述出系统行动的某些方面,所以呈文中各种图表有着极高的价值;固然它们不太难于懂得,但是客户可能对此并不熟习,因此客户能够要求分析人员说明说明每个图表的作用、符号的意思和需求开发工作的成果,以及怎么检讨图表有无过错及不一致等。

5、开发人员要尊重客户的意见 

如果用户与开发人员之间不能彼此理解,那对于需求的讨论将会有阻碍。独特配合能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并爱护他们为项目成功所付出的时间,同样,客户也应答开发人员为项目成功这一共同目标所做出的尽力表现尊重。

6、开发人员要对需求及产品实施提出倡议和解决方案

通常客户所说的“需求”已经是一种实际可行的实行计划,分析人员应努力从这些解决办法中懂得真正的业务需求,同时还应找出已有系统与当前业务不符之处,以确保产品不会无效或低效;在彻底弄清业务范畴内的事件后,分析人员就能提出相称好的改良方式,有教训且有发明力的分析人员还能提出增添一些用户不发现的很有价值的系统特性。

7、描述产品使用特性 

客户可以要求分析人员在实现功能需求的同时还留神软件的易用性,因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如:客户有时要求产品要“界面友好”或“硬朗”或“高效力”,但对开发人员来讲,太主观了并无适用价值。正确的做法是,分析人员通过讯问和考察了解客户所要的“友爱、健壮、高效所包括的详细特性,详细分析哪些特性对哪些特性有负面影响,在性能代价和所提出解决方案的预期好处之间做出衡量,以确保做出合理的取舍。

8、容许重用已有的软件组件

需求通常有一定机动性,剖析人员可能发明已有的某个软件组件与客户描写的需求很相符,在这种情形下,分析职员应供给一些修正需求的抉择以便开发人员可能下降新体系的开发本钱跟节俭时光,而不用严厉按原有的需要阐明开发。所以说,假如想在产品中应用一些已有的贸易常用组件,而它们并不完整合适你所需的特征,这时必定水平上的需求灵巧性就显得极为主要了。

9、请求对变更的代价提供实在牢靠的评估

有??同的选择。而这时,对需求变更的影响进行评估从而对业务决策提供赞助,是非常必要的。所以,客户有权力要求开发人员通过火析给出一个真实可托的评估,包括影响、成本和得失等。开发人员不能因为不想实施变更而随便夸张评估成本。

10、失掉满足客户功能和质量要求的系统

每个人都生机项目成功,但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息,而且还要求开发人员能通过交流了解清晰取舍与制约,一定要明白说明您的假设和潜在的盼望,否则,开发人员开发出的产品很可能无奈让您满足。

11、给分析人员讲解您的业务

分析人员要依附客户讲解业务概念及术语,但客户不能指望分析人员会成为该领域的专家,而只能让他们明白您的问题和目标;不要期冀分析人员能掌握客户业务的轻微潜在之处,他们可能不晓得那些对于客户来说天经地义的“常识”。

12、抽出时间明白地说明并完美需求

客户很忙,但无论如何客户有必要抽出时间介入“脑筋顶峰会议”的探讨,接收采访或其余获取需求的运动。有些分析人员可能先明确了您的观点,而过后发现还需要您的讲授,这时请耐烦看待一些需乞降需求的精化工作过程中的重复,因为它是人们交换中很天然的景象,何况这对软件产品的胜利极为重要。

13、准确而具体地说明需求

编写一份清楚、正确的需求文档是很艰苦的。因为处置细节问题岂但烦人而且耗时,因而很轻易留下隐约不清的需求。然而在开发进程中,必需解决这种含混性和不精确性,而客户偏偏是为解决这些问题作出决议的最才子选,否则,就只好靠开发人员去准确猜想了。

在需求分析中临时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的处所,有时也可能因为某个特别需求难以解决或没有人乐意处理它而标注上“待定”。客户要尽量将每项需求的内容都论述清楚,以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表白,通常就要求用原型技术,通过原型开发,客户可以同开发人员一起反复修改,不断完善需求定义。

14、及时作出决定

分析人员会要求客户作出一些挑选和决定,这些决定包含来自多个用户提出的处理方法或在质量特性抵触和信息准确度中取舍调和方案等。有权作出决定的客户必须踊跃地对待这所有,尽快做处理,做决定,因为开发人员通常只有等客户做出决定能力举动,而这种等候会延误项目标进展。

15、尊重开发人员的需求可行性及成本评估

所有的软件功效都有其成本。客户所盼望的某些产品特性可能在技巧上行不通,或者实现它要付出极高的代价,而某些需求试图到达在操作环境中不可能达到的机能,或试图得到一些基本得不到的数据。开发人员会对此作出负面的评估,客户应当尊敬他们的看法。

16、划分需求的优先级

绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的,哪些是重要的,是需求开发的重要局部,这只能由客户负责设定需求优先级,因为开发者不可能依照客户的观点决定需求优先级;开发人员将为您确定优先级提供有关每个需求的破费和危险的信息。 在时间和资源限度下,关于所需特性是否完成或完成多少应尊重开发人员的意见。只管没有人乐意看到自己所愿望的需求在项目中未被实现,但究竟是要面对事实,业务决策有时不得不根据优先级来缩小项目范畴或延伸工期,或增加资源,或在质量上寻找折衷。

17、评审需求文档和原型 

客户评审需求文档,是给分析人员带来反馈信息的一个机遇。如果客户认为编写的“需求分析报告”不够准确,就有必要尽早告诉分析人员并为改进提供提议。更好的措施是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员,使他们更好地舆解您的需求;原型并非是一个实际利用产品,但开发人员能将其转化、裁减成功能齐全的系统。

18、需求变更要立刻接洽

一直的需求变更,会给在预约打算内完成的质量产品带来重大的不利影响。变更是不可防止的,但在开发周期中,变更越在晚期涌现,其影响越大;变更不仅会导致代价极高的返工,而且工期将被耽搁,特殊是在大体构造已完成后又需要增长新特性时。所以,一旦客户发现需要变更需求时,请即时告诉分析人员。

19、遵守开发小组处理需求变更的过程 

为将变更带来的负面影响减少到最低限度,所有参加者必须按照项目变更把持过程。这要求不废弃所有提出的变更,对每项要求的变更进行分析、综合考虑,最后做出适合的决议,以断定应将哪些变更引入名目中。

20、尊重开发人员采用的需求分析过程

济南软件开发中最具挑衅性的莫过于收集需求并肯定其正确性,分析人员采用的方法有其公道性。兴许客户认为收集需求的过程不太划算,但请相信花在需求开发上的时间是十分有价值的;如果您理解并支撑分析人员为收集、编写需求文档和确保其品质所采用的技术,那么全部过程将会更为顺利。

“需求确认”象征着什么

在“需求分析报告&rdquo,手机店管理系统;上签字确认,通常被以为是客户批准需求分析的标记行为,然而实际操作中,客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名,于是我就签了,否则这些开发人员不开端编码。”

这种立场将带来麻烦,譬如客户想更改需求或对产品不满时就会说:“不错,我是在需求分析报告上签了字,但我并没有时间去读完所有的内容,我是信任你们的,是你们非让我签字的。”

同样问题也会产生在仅把“签字确认”看作是实现义务的分析人员身上,一旦有需求变革呈现,他便指着“需求分析讲演”说:“您已经在需求上签字了,所以这些就是咱们所开发的,如果您想要别的什么,您应早些告知我们。”

这两种态度都是错误的。因为不可能在项目的早期就了解所有的需求,而且毫无疑难地需求将会出现变更,在“需求分析报告”上签字确认是终止需求分析过程的正确方法,所以我们必须明白签字意味着什么。

对“需求分析报告”的签名是树立在一个需求协议的基线上,因此我们对签名应该这样理解:“我赞成这份需求文档表述了我们对项目软件需求的了解,进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们从新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍耐未来的摩擦,这些摩擦起源于项目的改进和需求的误差或市场和业务的新要求等。 需求确认将迷雾拨散,浮现需求的真面目,给初步的需求开发工作画上了双方都明确的句号,并有助于构成一个连续良好的客户与开发人