软件需求分析教程阅读笔记二

软件需求分析教程阅读笔记二

管理人员在要求开发一个系统时并不会理解进行需求分析的重要性,他们只知道能不能尽快开发出相应的系统来方便使用,但是如果不做好需求分析,最终开发出的系统也不会有人用。

客户的需求认识并不像软件开发人员这样,了解的比较清楚,客户通常并不懂得从系统的实际用户处得到信息的重要性,然而从产品的实际用户处收集需求有着不可替代的必要性,所以导致项目最终失败的两个原因,一个是缺乏用户参与,另一个是不完整的需求规格说明。

在进行需求分析时,只有系统的实际使用者才能清楚的描述他们要用此系统必须完成的任务。

开发之前要清楚客户的概念。客户指直接或者间接从产品中获得利益的个人或者组织。项目的风险承担着有义务说明业务需求,即产品的高层次概念和产品的主要业务内容。业务需求只是高层次需求,还需要从产品的用户处收集用户需求,能够了解该产品要完成的任务,必须要去实际用户处收集用户需求才会有准确性。如果上述两种需求无法分析明白,除非需求极为简单,否则必须要消除需求中模糊不清的地方和一些使程序人员感到困惑的方面。

客户与开发人员之间要协调好关系,不能总是只想着自已一方的利益,还要为对方的利益着想。在开发过程中,软件客户既有相应的权利,也有对应的需求,要清楚自己一方的权利与义务,来为整个开发过程服务。

在权利方面,

要求分析人员懂得业务术语,软件的使用可能会用到这些业务术语;

分析人员一定要去了解业务和业务目标,必须要编写软件需求规格说明书,这在以后的开发过程中是至关重要的;

开发过程中使用的图表及流程图或符号之类,软件客户有权利知道每一个表示的意义,并且要求开发人员尊重客户的意见;

客户在描述产品性能时,很可能会用词非常主观,用词并不确切对于开发者来说,这样很可能会导致最后开发的产品不能让用户满意,所以描述的时候,分析人员要询问了解客户所要求的具体特性,要定量化的描述;

需求具有灵活性,是可稍微变更的,同客户分析之后,将需求变得灵活一点,这样就可以重用一些已有的软件组件,既能降低成本,也能节省开发时间,先同客户分析,再变更。

在变更需求时,会对软件开发的成本或者其他方面会有影响,这时客户可以要求开发人员分析给出真实可信的评估,开发人员不可以不想变更需求而主观随意夸大成本。

在义务方面,

在进行开发之前的需求分析阶段,客户需要给分析人员讲解业务概念和术语,因为分析人员需要使用这些术语来明白系统的问题和目标而开发出符合要求的系统。如果客户很忙,也需要客户抽出时间来进行详细的讲解。

需求规格说明书是一份很重要的说明,但是里面的内容不一定都能正确理解,所以必须要解决这个问题,可以在说明书中加上一些标记来方便日后的阐述。

在需要客户做出决定时,客户尽量根据当时条件,及时准确的做出决定,这样才不至于延误项目进展。

客户说明需求之后,开发人员会对这些需求进行可行性分析和成本的评估,客户要尊重分析人员进行的评价,从而来决定是否要调整需求。

分析人员了解需求之后,会提供每个需求的话费和风险的相关信息,这时客户应该根据这些信息来划分需求的优先级,从而使开发者在一定的时间内用最小的开支来取得最好的效果。

在书写完成需求规格说明书之后进行开发之前,需要让客户参与需求文档的评审,这样可以给分析人员带来反馈信息,尽早告知分析人员相关的建议,这样可以大大节省后期开发的时间,并且出错的概率也会大大降低。但是仅凭一份文档,用户很难知道软件是什么样子的,开发人员要做一个原型系统来提供更有价值的信息。

开发过程中,如果要变更需求,客户一定要马上联系开发人员,否则越是到开发后期,成本会越高,并且开发时间也会延长。

最后最重要的是,客户一定要理解分析人员在需求分析上花费的功夫,因为这个是非常必要的。

当需求规格说明书完成之后,客户需要在说明书上签字。这意味着客户同意终止需求开发过程,表明客户同意文档表述了目前项目需求的了解,如果以后要做变更,可以基于一定的准线来进行变更,虽然这有可能会影响到成本、资源、和项目工期等方面的问题。明白这些之后,就明白签约的意义了,并不只是签个名字的意义,这会在以后的开发工作以及提出需求变更时,仍能让双方满意。

时间: 2024-10-14 04:51:15

软件需求分析教程阅读笔记二的相关文章

软件需求分析教程阅读笔记一

软件需求分析教程阅读笔记一 许多工程项目不能按时完成或者最后导致失败的一个很大的原因就是弄不清需求是什么,不能准确理解客户的需求意图,所以前期做好需求调研是一件非常重要的工作,是一件与系统代码开发占有同等比重的工作. 读这本书的同时,要注意实践过程,不必非得要从一个新项目开始应用,可以找一个以前的或者是现在正在进行的项目,根据书中所讲,着手开始实践. 软件需求就是需要知道是什么和为什么. 在软件开发当中遇到的许多问题,都是由于收集,编写,协商,修改产品需求过程中的手续和做法失误所带来的.需求分析

02《火球——UML大战需求分析》阅读笔记之二

02<火球----UML大战需求分析>阅读笔记 在上一次的阅读笔记中,:我阅读的是开始部分和第一章,总结了其实UML不仅对于软件设计有很大的用处,对于软件的需求的分析也处于很高的地位.现在,读了第二章,真正的明白了UML对于需求分析的真正用处. 其实客户与我们所处的关系和医生与病人之间的关系,认识永远存在着偏差,就像对于用户和软件公司,对于需求的分析永远的存在着偏差.因为对于客户而言,每天的需求总是多变的,并且词不达意--à分析员的错误理解--à程序员的错误编码----à返回客户,客户的不满意

寒假阅读笔记二

大型网站技术架构-阅读笔记二 模式:每一个模式描述了一个在我们周围不断发生的问题及该问题解决方案的核心.这样你就能一次又一次地使用该方案而不必做重复工作. 分层:将系统在横向维度上切分成几个部分,每个部分负责一部分相对比较单一的职责,然后通过上层对下层的依赖和调用组成一个完整的系统.分层时必须合理规划层次边界和接口,在开发过程中,严格遵循分层架构的约束,禁止跨层次的调用(应用层直接调用数据层)及你想调用(数据层调用服务层,或者服务层调用运用层). 分割:网站越大,功能越复杂,服务和数据处理的种类

构建之法--阅读笔记二

阅读笔记二—代码规范 代码的风格的原则就是:简明,易读,无二义性.我虽然是计算机系的学生,但是我以前却没有秉着这个原则来编写代码,现在阅读了构建之法后,我明白了如何让你的代码变得简明,更容易理解. 代码在编写的过程中注意: 用Tab键缩进 要注意行宽,最多限定100字符的行宽 在复杂的条件表达式中,用括号清楚地表达逻辑优先级 要注意断行与空白的{ }行,有明确的“{”和“}”来判断程序的结构 不要把过多的语句放在同一行上 对变量命名要有实际的意义 用下划线来分隔变量名字中的作用域标注和变量的语义

《逻辑思维简易入门》(第2版) 阅读笔记二

<逻辑思维简易入门>(第2版) 阅读笔记二 本周阅读的是<逻辑思维简易入门>的第三章,也就是说,本书的第一部分就已经读完了. 第三章.信念的优点 信念和负信念是人们在接受一个事物时一种心理态度,延伸来说也就是对事物的认知态度.因为我们在研究 逻辑思维的时候,都有一个前提:“以正常情况以及说话者真诚”,所以有人如果对于一件事物不做回应,我们可以认为这是一种既不相信,也不怀疑的的态度. 信念的优缺点有很多,在书中主要介绍了下面几种: 1.准确性 好的信念实在准确的表达事实,同样真的信念

《软件需求十步走》阅读笔记二

这一段时间阅读了<软件需求分析十步走>的第三四章,写一写书中一些个人感觉比较好的说法以及阅读感受. 首先是第三章<软件需求工程概论>. 需求工程和软件工程之间的关系界定没有质的变化,只是将需求工程从软件工程中剥离出来,将需求分析的分析工作和管理工作定义为需求工程.需求工程是面向全局的.系统顶层的.着眼未来的工程,是将客户业务作为内部研究对象,将软件工程全过程作为外部研究对象的工程.需求工程是圆心,软件工程是圆点. 需求工程的特征具有:全局性.主导性.主动性.过程性.规范性.可验证性

《构建之法》阅读笔记二

第二章阅读笔记 软件工程师的个人技术之一软件测试:    软件测试在软件开发流程中占据非常重要的地位. 单元测试:因为大多数软件工程师都是团队合作,所以其开发的模块其他人很有可能会用到,所以保证模块的正确性.完善性是非常重要的,所以就要进行单元测试来对模块的功能进行验证,验证要保证各种数据都能通过,对于特殊的数据都要进行验证,这样才能保证模块的健壮性.单元测试应该准确.快速地保证程序基本模块的正确性. 回归测试:软件的模块在进行修改或者新增后要进行回归测试,测试原来的功能是否受到影响. 效能分析

《我们应该怎样做需求分析》阅读笔记

阅读笔记如下: 新的学期又开始了,所以新的目标要被确定了,今年又加入了考研的队伍,所以一定加油!! 近年来,软件业发展突飞猛进,但一个软件项目要做好的前提还是软件需求分析,从作者分享的故事中我总结了以下几点: (1)要对客户的需求进行深入的了解,而并非一味地被客户牵着鼻子走,从业务角度深入进行分析,有没有更好的方案对客户需求进行改进,使变更变得更加可控. (2)作为技术人员,需求分析必须实事求是.基于技术可以实现的角度去考虑.去引导客户的需求,而非一味地鲁莽行事.做需求应当首先理解现有的管理模式

《大道至简---软件工程实践者的思想》阅读笔记二

08大道至简——软件工程实践者的思想阅读笔记之二 2015-06-02 16:41 第五章 失败的过程也是过程 以得失而论,在瀑布模型与RUP模型之间,学习前者而不成,可思过程的本质:学习后者而不成,可得文字的架子. 如果懂得了所谓的模型原本都演化自那个简单的瀑布,那么文档是按XP写还是按RUP写,也就可以应时.应需,因地置宜,择善而从了. 越是简单的东西,往往越是接近于本质. 项目经理的工作,就是要去组织这个工程中的各个角色,使得分工明确,步调一致,共同地完成这个项目. 第六章从编程到工程 我