《软件需求最佳实践》阅读笔记一

这本书主要从软件需求实践中出现的主要问题和困难入手,指出了改造的主要方法,然后逐一说明了需求定义、需求捕获、需求分析与建模、编写规约、需求验证等需求开发活动的任务、要点和具体手段。还对包括需求基线、变更管理、需求跟踪在内的需求管理活动的操作要点进行了阐述。

软件项目实施过程中,会遇到很多的问题,有的甚至许多项目根本无法达到预期的目标,这些问题的根源就是软件需求实践。“在中国做软件太难了!客户连自己的需求都说不清楚!”,这种抱怨的话经常被做软件需求的人说到。需求失败也是因为不完整的需求、缺乏用户参与、不切实际的用户期望、需求变更频繁等原因。在很多软件项目中,用户总是不能有效的参与到项目中来,而主动参与意识与获得的利益是成正比的,为了让用户参与进来,要充分研究不同用户代表的关注点、利益点。对项目的沟通上一般会出现沟通失真的问题,解决这个问题的有效方法是及时复述。而往往客户的需求会被放大,这时候需求分析人员则有必要对需求进行有效的控制。需求的本质在于业务分析并不是技术分析,构造适当的业务场景也是需求所必须的。需求问题一直是一个很大的困扰,需要透过表象、分析本质、总结经验。

在信息系统、嵌入式系统、软件产品等不同角度都有着相应的需求工作,这些能够为需求分析师提供一个切实有效的视图。要更科学的对不同的软件需求进行分析,就需要根据不同的项目选择不同的线索。流程是联机事物处理系统需求视图的关键线索。在信息系统中,目前需求开发的思想提倡从用户的场景出发,从业务流程出发的横向视角。在嵌入式系统中,具体的使用场景是需求的主线索,对于面向用户的嵌入式系统,行为分析是要点;面向特定设备的嵌入式系统,外部接口和事件分析是要点;而软件产品分类则跟联机事务处理系统、管理信息系统等不同,与软件产品对应的是软件项目。

软件需求根据经验来讲可以定义为“业务知识+问题列表+其他因素”。需求的三个层次:业务需求、用户需求和软件需求。业务需求是反映企业/组织对软件系统的高层次目标要求,即软件系统的建设目标,体现在问题和机会两方面,是需求定义的产物;用户需求是指用户使用软件需要完成什么任务,怎么完成的需求,即用户需求是需求捕获的产物;软件需求又称系统需求,是需求分析与建模的产物。一个优秀的需求标准包括:完整性、不失真、有优先级、有技术早期介入等方面。需求工程包括需求开发和需求管理两大范畴,需求开发重点在于开发出高质量的需求规格说明,需求管理重点在于确保开发的软件满足需求。

需求定义就是要确定项目的宏观需求,即定义项目的业务需求,也就是明确的目标和范围。问题分析,就是理解真实世界中的问题和用户需求并提出满足这些多方面的解决方案的过程,要正确定义问题,然后寻找问题的解决方案,但是在确定某个解决方案时,一定要思考是否会引发新问题。在问题被定义之后,接下来就要分析问题背后的问题,也就是寻找问题的本源,然后就可以明确与项目相关的人。在需求定义这个阶段,对系统的范围进行界定十分重要,一般都使用上下文关系图来确定系统的范围,即数据流图中的顶层图,即将整个待开发系统理解成一个黑匣子,标识出外部的参与者和系统与其的交互关系。范围是涉及事、物,边界是人与系统的职责边界。之后可以通过业务事件列表和报表列表将主题域内容显示出来。业务事件分为外部事件(来自系统外部的事件,系统参与者发起)和内部事件(系统内部触发)。

目前看的这本书的这些内容有很多地方都涉及了老师上课讲的知识,更深层次的理解了那些课上比较重点的知识,通过一个个案例学会了思考问题的方式和解决问题的办法。软件需求过程很重要,关联着一个项目的成功与失败。要明确软件需求,尤其是业务需求、用户需求和系统需求,这一部分非常重要;同时明确好上下文图,确定系统的边界及每一个业务事件。

时间: 2024-10-07 06:18:20

《软件需求最佳实践》阅读笔记一的相关文章

梦断代码阅读笔记有感之二

08梦断代码阅读笔记有感之二 在梦断代码的一开始我们就学会了如何去写代码,如何成功的去做一个软件工程师. 在现在人的严重,也许软件工程师写出的代码只是让人在玩游戏,在用一些简单的用代码写出的软件.只是认为工程师在不断地重复着一个动作:写代码.但我只能说你们大错特错,就像在文章中说的那样,其实软件工程师是在:“改变世界”,他们利用他们的手用键盘在电脑上打出一行一行的代码,程序产生了,一个新的软件也就产生了.而且,众所周知的,工程师做一个软件,总是在无限制的更新他的内容,让我们的软件更加的先进化,就

梦断代码阅读笔记有感之三

09梦断代码阅读笔记之三 这是最后一篇的阅读笔记,我发现时间真的过的好快好快. 想想以前,我们总是在应付一切的差事,但是真正的到最后,我们才发现,到最后吃亏的还是我们自己. 从前的我们,我们总是对自己大脑中的东西一片一片的特别的混乱.其实我们就像作者所说的,我们就像放任胡乱的cd随地的乱放,到最后不知道哪是哪.我们应该学会分类去放置,例如:我们可以根据歌唱者的名字,音乐的类型等等,其实这些东西对于我们写代码也同样的试用,刚开始的上大一时候,我们第一次的学习C++,我们只是随时随地的在写代码,并不

梦断代码阅读笔记之一

最近阅读了罗森伯格的<梦断代码>,算是近距离观察了十几年前软件开发的状态.这本书是作者对OSAF主持的Chandler项目进行田野调查  而写的一本书.本书是在讲一事,也是在讲百千事:是写一软件,也是在写千百软件.在描述Chandler项目的过程当中亦提出了很多观点,带给我们很多思考.让我们这些软件工程专业的学生对软件开发有了一个更深层次的认知. 在本书第一章,作者为我们介绍了一个布鲁克斯法则:"往已延误的项目里补充人力,只会使其继续延误". 布鲁克斯曾是IBM的资深程序经

&lt;&lt;梦断代码&gt;&gt;阅读笔记一

没有想象中的枯燥,甚至有些有趣.这就是我对<梦断代码>这一本书的第一印象.而且,作为一本面向程序员的书籍,作者很有意义地从第0章开始,那我也从第0章开始说.这第一次读书笔记是针对0~2 章的. 首先,作者一开始就向我们介绍了程序员的真实生活:代码.日期.紧张.焦虑.这是我从书中体会出来代表程序员的词 语.我第一次感到编程可能是一件辛苦的事,回想自己编程的时候,只是歇一歇简单的短的程序,没有压力,没有焦虑,但是在真正的公司.项目中,程序员要面对的是茫茫代码以及对未来的未知,因为没有人能确定自己从

&lt;&lt;梦断代码&gt;&gt;阅读笔记三

看完了这最后三分之一的<梦断代码>,意味着这本软件行业的著作已经被我粗略地过了一遍. 在这最后三分之一的内容中,我深入了解了在大型软件项目的运作过程中存在的困难和艰辛.一个大型软件项目的成功代表着这团队所付出的所有心血,以及那不为 人知的无数个‘人月’.而联想自己的专业,产生了一点迷惘,这就是我今后要走的道路么,我能走得多远,我能否像书中所提到的那些人一样百折不挠,这一切我 都无从得知.但是我只能向前走,别无选择,没有人会承认自己不如别人,哪怕现在不如,但总会寄托于未来,未来是未知的,但又是现

梦断代码阅读笔记二(4-7章)

在上一周<梦断代码>读完了第七章,全书已经过半,对于这本书有了更深的体会,对于软件开发之难也更加理解.      乐高王国一章中引出了一个代码世界或者说程序员世界里的美好设想——程序将由可复用的部件组合而成,软件部件将在全球范围内提供,软件工程将从编程的窠臼中解放出来.软件组件就像乐高积木一样,细小.不能再分.可被替代.可以自由组合.这是代码复用的概念,这会省去编写代码的麻烦,但是也存在不少问题,诸如大型可复用组件的稀少,有些程序员不愿拾人牙慧等等.其实我认为这是一个不错的设想,也是一个值得努

01梦断代码阅读笔记之一

在看完构建之法之后,我又开始了梦断代码的阅读. 在梦断代码的第0章就写作者从15岁的玩游戏,但是对于当时的他来说,并不是在沉迷于游戏,而是为了做到打补丁.使得自己的少年的梦想得到浇筑.其实他的做法正应该体现在我们现在学习软件人的身上,我们现在就应该学会怎样的去做自己的梦想,更重要的是练习自己对于软件的好奇心以及热爱,在作者40岁的时候,我们体现的又是另一种的感觉,其实他们和我们没有差别,就像我们在做一个软件的时候,我们在到达最后的期限的时候,其实在哪个时候我们才发现我们什么都没有做出来,问自己为

梦断代码阅读笔记01

大致浏览了一下<梦断代码>这本书,觉得还是挺感兴趣的.第一章软件时间,作者以一名程序员的身份自述,故事性很强,读起来不会感觉枯燥.在第一章中作者认为程序员与其他人的不同之处在于他们从一开始,而我们从零开始,想来也正是如此,他谈了软件的发展历程以及过程中好多伟大的研究者为其发展而做的贡献,这个行业也是很多前辈付出了诸多努力才推出来的,所以需要我们付出更多的努力去发展他. 第二章中作者讲到我们做任务需要蓝图,也就是需要有计划,提前计划好,按计划来做任务,这样对于碰到一些问题才不至于举手无措,另外在

梦断代码阅读笔记二

今天看了<梦断代码>的第2章-Agenda之魂,刚开始看时不知道Agenda是什么东西,看完之后才知道是什么东东,这里先不做解释,下面会详细介绍到.说到Agenda,就必须提一下米奇·卡普尔这个人,卡普尔曾被冠以“反盖茨”的名号,由于他不喜欢使用Exchange,但当时小型组织的日程管理没有其他方案可选,但是用Exchange的代价不低,你得购置一台服务器,购买Windows许可,购买Exchange软件许可,如果没有全职技术人员,还得雇个咨询师.可能基于这个背景的情况下,卡普尔大胆押宝,创建

梦断代码阅读笔记一。

梦断代码有第零章.其表达了软件是人类文明的延续,我也认同这种看法.确实如作者所说,人类没有Microsoft Windows文明也会延续下去.但没有软件,人们的工作效率就会很低.就像我所想的那样,多少年以后,很多公共设施和家庭设备都会是智能的,甚至可以和手机“交流”.作者还表达了身为程序员的一种可悲,我感同身受.生命中省下的好日子,都会耗费在给自己的程序找错误的时间上. 我们确实“死定了”,如果继续把自己程序的错误找下去,不说这辈子,这学期肯定是不够的.从表面上看来,这个错误看起来很简单,用两三