软件需求分析——阅读笔记6

读《需求工程——软甲建模与分析》 第五部分 需求管理与工程管理有感

  在需求开发活动之后,需求基线应该成为后序软件系统开发的工作基础和粘合剂。需求管理在需求开发之后的产品生命周期中保证需求作用的有效发挥。作为需求开发的结果,最终的需求应该被明确和固定,需求基线就是被明确和固定的需求集合,是项目团队需要在,某一特定产品版本中实现的特征和需求集合。需求基线是需求开发过程中的成果总结,他需要在后续的产品生命周期中持续发挥作用。因此,需求基线要以一种持续、恒定和易于项目涉众访问的方式存在,通常的做法是将需求基线编写成正式的文档,纳入配置管理。

  重要的需求描述信息包括:标识符、当前版本号、源头、理由、优先级、状态、成本、工作量、风险、可变性等。需求描述信息的收集、存储和维护是一个繁琐的工作,所以在必要的情况下,可以使用专门的需求管理工具作为辅助手段。

  将需求基线纳入配置管理,它的主要工作有:标识配置项、版本控制、变更控制、访问审计、状态报告。

  需求基线是需求开发阶段之后各种项目工作的基础,他也能很好地反映各种项目工作的进展状况,进而反映整个项目的实际进展状况。

  需求跟踪是以软件需求规格说明文档为基线,在向前和向后两个方向上,描述需求以及跟踪需求变化的能力。它分为前向跟踪和后向跟踪。需求跟踪的实现是一个需要进行大量手工劳动任务,需要组织提供支持。在系统开发和维护的过程中,一定要随时更新这些联系链信息,如果信息已经过时,就可能再也无法重建这些信息了。

  在实际工作中,需求跟踪实现的具体内容是依赖于项目的跟踪策略的。不同的项目有不同的策略需要,会实现不同的需求跟踪联系。将项目的跟踪策略分为三个不同的层次。最低的层次上,需求跟踪仅仅捕获产品内容各个系统组件之间的依赖、满足和实现关系。在一个更高的层次上,还要捕获各个组件之间的联系,还要捕获各个组件的工作背景。除了产品本身所包含的各种联系之外,项目的组织过程也应该是需求跟踪内容的一个部分。实现了工作背景和过程背景捕获的需求跟踪是闲着被称为高端用户。

  需求跟踪的实现方法主要有矩阵、实体联系模型和交叉引用三种。

  在需求跟踪的各种联系中,有一种特殊的跟踪依赖——需求依赖。大多数的需求并不是完全独立的,它们在一种复杂的机制中互相影响,这就是需求依赖。需求开发是一个获取、明确并定义的需求过程,但需求并不是在需求开发结束之后就会恒定不变的。需求的变更时正当和不可避免的,在需求开发之后冻结需求是不恰当的做法。正确的做法是在形成需求基线之后,进行需求的变更控制。

  变更控制中的注意事项:(1)认识到变更的必要性,并为之制定计划。(2)维护需求基线,审计变更记录。(3)管理范围蔓延。(4)灵活应对变更请求。(5)使用辅助工具。

  需求的不稳定性和对实践的调查和研究中一再被发现和关注。认为对需求变化的有效处理是项目成功的关键因素。将“需求变化”和“糟糕的项目计划”并列为导致项目失败的两个主要因素。

  需求工程需要依赖的环境因素有:市场特性、领域特性、技术成熟度、组织文化、项目特性。

  建立需求工程过程包括两个步骤:(1)建立过程框架,建立需求工程的高层结构,说明过程中应该包括哪些工作部分以及怎样建立它们之间的协作和联系。(2)选择工作组件,为过程框架下的每一个过程工作部分选择实现的时间方法,明确需要的工具支持和资源支持。

  软件项目的目的就是保证所有重要的工作都能得到应有的关注,都能顺利有序的完成,以最终产生高质量的软件产品。

时间: 2024-11-05 22:34:18

软件需求分析——阅读笔记6的相关文章

软件需求分析——阅读笔记5

读<需求工程--软件建模与分析> 第四部分 需求的文档化和验证 有感 需求获取活动收集了需求信息,需求分析活动深入地理解了需求信息并建立了能够满足用户需要的软件解决方案.而需求规格说明活动就是将需求及其软件解决方案进行定义和文档化,并传递给开发人员的需求工程活动. 需求规格说明文档是需求规格说明活动的一个核心元素.(1)需求规格说明文档可以成为各方人员之间有关软件系统的协议基准.(2)需求规格说明文档可以成为项目开发活动的一个重要依据.(3)在需求规格说明文档的编写过程中,可以尽早的发现和减少

软件需求分析阅读笔记

今天读了关于如何做需求分析的博文,学习了软件需求与分析需要掌握的一些内容,下面就做一些总结. 首先要认识到深入地去理解客户的业务,进而想到客户的心坎儿上去,最后做出来的东西必然是客户满意的.第一个举出来东软的例子,东软在做这个项目的时候,整个过程经历了10多次结构性的大变更,局部性的调整更是不计其数.百处程序进行修改.最后这个项目导致的结果是,整个这个项目组的所有成员都离开了东软,常常会听到抱怨客户总是对需求改来改去,那是因为我们对客户的需求没有真正理解清楚时,我们做出来的东西客户必然不满意.不

UML大战需求分析——阅读笔记04

读<UML大战需求分析>有感04 开发某系统的重要前提是: 这个系统有谁在用? 这些人通过这个系统能做什么事? 一般搞清楚这件事,再画个业务流程图,就能条例清楚的表达系统的需求了.作为一个开发人员,不仅要懂得如何从用户那里获取有用的信息,还要懂得怎么清晰地描述自己的想法,给客户呈现出一个结构完整.功能全面的系统原型.那么,这些必备的画图技巧,就会帮上很大的忙. 用例图是用处非常广泛,使用频率最高的UML图,它用来描述什么角色通过某某系统能做什么事情,关注的是系统的外在表现.系统与人之间的交互.

软件方法阅读笔记(一)

<软件方法>讲的是用UML语言来辅助我们进行软件的从0到1的过程.这个过程的结果并不是最终运行在电脑屏幕上的那个界面,而是一堆图纸,可视化的图纸.是的,确实是图纸.建筑行业有设计和施工图纸,电工行业有设计和实施图纸,城市规划有图纸··· ···任何你看得到的工程都有图纸,你要写的软件居然没有.“图纸在我脑子里呢”,我也曾经说过.直到看到这本书.这本书的直接受众应该有两类人:1.程序员这类人一般的工作思路就是提功能的人说要做什么,嗯嗯哦哦之后,迫不及待的打开编辑器开始写代码,调试,然后发现做完的

《UML大战需求分析阅读笔记》05

我阅读了一个例子,一个软件公司采用.NET技术体系研发了一套电力系统,该系统使用的是SQL SERVER数据库.但安装系统时,客户发现该系统使用的数据库是SQL SERVER时,要求必须使用Oracle,如此一来,软件公司只能修改系统,这样的软件改动工作量是很大的.所以一定会需要软件技术框架,如果忽视了在软件技术框架.软件架构上的要求的话,会给软件后期工作带来想不到的麻烦.很多项目往往在初期就会对技术框架有一定的限制,常见的情况有:1.新项目需要在原系统的基础上开发:2.新项目需要与某些存在的系

林锐——软件思想阅读笔记2

本章作者给我们讲述了可行性分析和需求分析的重要性和其中的一些问题.可行性分析就是要知道这件事情能不能做成功,而需求分析讲的是我们该做什么不该做什么.一般影响可行性分析的因素有经济,技术,社会环境和人 . 经济方面我们首先要考虑成本和收益问题,在考虑这个问题时我们要把成本算仔细,不管是前期还是后期维护我们都要考虑清楚,要不会给你带来很大的麻烦,然后就是短期利益和长期利益的关系了,我们都想短期利益和长期利益兼得,但是鱼和熊掌大部分时间是不能兼得的,所以作为一个有远见的人我们要能为了长期利益而放弃短期

软件需求阅读笔记01

建筑往往是根据设计图来完成的,软件也不例外,一个项目的质量和设计规划图有着密不可分的关系.这之间的联系,简单来说,便是用户和工程师的沟通,用户说出自己的需求来让工程师去实现.而需求包括三个不同的层次--业务需求.用户需求和功能需求,需求使问题变得明确,它是一一指明实现说明的规格说明,描述了系统的行为.特性或属性,是在开发过程中的约束. 需求的质量高低对于程序员来说很重要,实行有效的需求工程管理的组织能火得多方面的好处,其中最大的好处是在开发后期和整个维护阶段的重做的工作大大减少了.正确的需求过程

软件需求阅读笔记

案例: 某大银行的一位银行卡办公室的收账经理Liz遇到了一个问题.她每周都收到一份过期未付款的账户名单.这份报告已经从两年前的250个账户增加到现在的1250个账户. 为了确定那些严重拖欠债务的账户,Liz需要通读这份报告.严重拖欠债务的账户由几个不同的规则确定,每个规则都要求Liz检查客户的一项或几项数据.过去半天的工作量现在增加到了每周三天.即使在确定了严重拖欠债务的账户后,如果没有查阅该账户三年内的历史资料,Liz也不能做出最后的信用决定(例如严厉的催款电话.断绝信用或将这个账户转给一个收

软件需求阅读笔记3

IEEE对需求定义为:①用户为了解决问题或达到某些目标所需要的条件或能力.②系统或系统部件为了满足合同.标准.规范或其他正式文档所规定的要求而需要具备的条件或能力.③对①或②中的一个条件或一种能力的一种文档化表述.通过这个定义了解了需求并不是用户想要的,想实现的,了解了需求本质的内涵. 功能需求是软件系统需求中最常见.最主要和最重要的需求,同时也是最为复杂的需求.功能需求通常体现为三个层次:业务需求.用户需求.系统需求. 业务需求描述了组织为什么要开发系统,满足用户的业务需求.业务需求是用户需要