软件需求十步走读后感1

软件需求是软件项目和产品开发的起点,更是用户和开发团队之间沟通的基础。软件需求的获取,规约,验证和管理在软件开发中占有举足轻重的关键位置,软件需求工程早已成为软件工程中一门独立关键的研究学科。

软件需求从何而来?又到何处去?需求从客户那里来,到开发人员那里去,最终客户和软件开发组织共同拿着软件需求对软件产品进行验收。所以软件需求是面向客户方和软件开发方,将双方的诉求进行有机结合,最终形成双方持有的一个契约。

人们总是觉得软件需求对比软件设计和开发是一个十分简单的事,但是很多人却做不好,而人们面对软件项目失败原因都归结于需求不完整,不清晰,不准确,总变化。不成功的软件开发中属于需求分析造成软件设计的错误和缺陷约占64%,而属于代码的错误仅仅占软件失败的36%,也就是说,软件需求分析是提高软件质量的基础,也是决定一个软件项目成败的关键。可以说软件需求的分析的成功与否决定了软件的质量好坏。而很多人在软件开发前不重视需求分析,等项目失败后再来想问题,每次都是这样,那么软件质量肯定不会特别高。

一个软件如果没有明确的需求分析,甚至压根没有需求分析,进行代码设计的过程中也会手足无措,不知道做什么。就像我们在素描或者写数学题的时候都需要去打草稿来分配位置,如果没有精确的分析,那么势必无法完成一个令人满意的作品。因此要注意软件设计钱前的需求分析阶段,虽然需求分析所用时间并不长,但是也决定了你以后的写项目的效率,有一个完全的需求可以让你在写代码的阶段如鱼得水,事半功倍,而残缺或者考虑不周到或者不重视需求,就会事倍功半,处处遇到绊脚石。

以前看到王建民老师发了那么多的需求,我就想为什么不一次直接发最后一版的需求,那样就不用改来改去的了。但是现在想起来,原来需求是一直变化的而不是刚开始制定完就不变了,老师想要我们适应这种变化,也就是相当于在企业工作一样,根据不断变化的需求来改变自己的代码,也在锻炼我们的对代码的重构能力,不可能我们接到一版需求,就重新写一次,那样效率太低,也在浪费时间,因此这也是对我们重构代码能力的一种锻炼。

而回到书中,书中明确提到,对需求分析工作事前千夫所指是有益的,而时候千夫所指是无谓的。这句话虽然用到了千夫所指这个词两遍,但是仔细想来,意义却是不一样。软件设计之前,你可以去使劲问别人怎么样怎么样,有什么模糊的地方,有什么没说清的地方都可以问出来,因为软件还没开始写代码,所以一切都是有意义的,用一句话来说,就是现在问的越详尽,越详细的需求可以使你再软件设计路上走得弯路更少,而软件验收交接的时候失败了,令人失望,那么这个时候再去职责别人怎么样,什么需求不详细,太模糊已经饿米有了意义,因为已经失败了,再去职责别人已经没有用了。

到了你现在会发现,写代码写的好的人很多很多,根本数不过来,但是他的需求能力不一定会和他的写代码实例匹配,也就是说以前,限制软件的成功失败与否是敲代码的人,但是现在已经成为了需求人员。因为木桶理论,大家都懂,短板会限制整个系统的好坏。

声明:该文章系转载,转载该文章的目的在于更广泛的传递信息,并不代表本网站赞同其观点,文章内容仅供参考。

本站是一个个人学习和交流平台,网站上部分文章为网站管理员和网友从相关媒体转载而来,并不用于任何商业目的,内容为作者个人观点, 并不代表本网站赞同其观点和对其真实性负责。

我们已经尽可能的对作者和来源进行了通告,但是可能由于能力有限或疏忽,导致作者和来源有误,亦可能您并不期望您的作品在我们的网站上发布。我们为这些问题向您致歉,如果您在我站上发现此类问题,请及时联系我们,我们将根据您的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。