软件需求阅读笔记3

IEEE对需求定义为:①用户为了解决问题或达到某些目标所需要的条件或能力。②系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力。③对①或②中的一个条件或一种能力的一种文档化表述。通过这个定义了解了需求并不是用户想要的,想实现的,了解了需求本质的内涵。

功能需求是软件系统需求中最常见、最主要和最重要的需求,同时也是最为复杂的需求。功能需求通常体现为三个层次:业务需求、用户需求、系统需求。

业务需求描述了组织为什么要开发系统,满足用户的业务需求。业务需求是用户需要在业务上使自己更加方便的开展工作的需求。

用户需求表达了用户对系统的期望,但是要透彻和全面地了解用户的真正意图,仅仅拥有期望是不够的,还需要期望的背景知识。因此,对所有的用户需求,都应该有充分的问题域知识作为背景支持。而在实际工作中,用户表达自己的期望时,通常不会提及需求所涉及问题域知识,所以需求工程需要根据用户的需求整理完整的问题域知识。

系统需求是用户对系统行为的期望,一系列的需求联系在一起可以帮助用户完成任务,达到用户需求,进而满足业务需求。需求工程可以直接映射为系统行为,定义了系统中需要实现的功能,描述了开发人员需要实现什么。

将用户需求转化为系统需求的过程,在该过程中,首先需要分析问题领域的特性,从中发现问题域和计算机系统的共享知识,建立系统的知识模型。然后将用户需求部署到系统模型中,即定义系列的系统行为,让它们联合起来实现用户需求,每一个系统行为即为一个系统需求。

需求工程的应执行的路线:1.问题分析:明确问题;定义业务需求;制定解决方案及系统特性。2.需求获取 3.需求分析  4.文档化和验证。需求工程的执行路线简明地展示了一个需求工程如何运行的流程,也了解了需求工程的整个过程。

书中也列举了常见的需求定义错误,更好地解释了之前需求的定义,也更加让我们了解了需求的定义,以及产生需求定义错误的原因,通过分析原因可以让我们在实际过程中注意到并且避免。也可以有更好的方法来避免这些错误。

需求工程活动:1.需求获取;2.需求分析;3.需求规格说明;4.需求验证;5.需求管理

需求获取是从人、文档或者环境中获取需求的过程。在需求获取中,需求工程师需要执行的任务包括:1.收集背景资料;2.定义项目前景和范围;3.选择信息的来源;4.选择获取方法,执行获取;5.记录获取结果。

需求分析的主要工作室通过建模来整合各种信息,从而使人们更好地理解问题。在需求分析阶段,需求工程师主要的任务包括:1.背景分析;2.确定系统边界;3.需求建模;4.需求细化;5.确定优先级;6.需求协商

需求规格说明:获取的需求需要被编写成文档,其中项目前景和范围文档记录记录业务需求、用户需求分析记录用户需求、系统需求被写入需求规格说明记录系统需求。需求工程师在这个阶段的主要工作包括:1.定制文档模板;2.编写文档

需求验证:为了保证以上标准的,满足,需求规格说明文档,尤其是最终定稿的需求规格说明文档,在传递给相关人员之前要进行严格的验证。需求验证阶段的主要任务包括:1.执行验证;2.问题修正

需求管理:需求管理会进行变更控制,纳入和实现合理的变更请求,拒绝不合理的变更请求,控制变更的成本和影响范围。需求管理阶段的主要任务包括:1.建立和维护需求基线集;2.建立需求跟踪信息;3.进行变更控制

这一部分详细介绍了需求的定义及分类,需求过程的活动,使我们了解了需求工程的作用和意义,明确了软件需求的来源和去向。还针对需求工程中理论与实践并重的现状,对理论、技术和实践方法进行了融合。

原文地址:https://www.cnblogs.com/837634902why/p/8504232.html

时间: 2024-10-10 11:15:33

软件需求阅读笔记3的相关文章

软件需求阅读笔记01

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

软件需求阅读笔记02

如果一个项目缺乏明确的规划和良好的信息交流途径,那将是十分糟糕的.如果项目的参与者持有不同的目标和优先权,那么他们只能各抒己见,无心工作.如果项目的风险承担者在产品所能满足的业务需要和产品所能提供的利益问题上不能达成一致的意见,那么需求决不会稳定.一个清晰的项目视图和范围过于分散在多个地方开发,在这样的项目中,地理位置上的分离使项目开发组成员必须天天进行相互沟通才能保证他们之间能进行更有效的合作. 项目视图可以把项目参与者定位到一个共同和明确的方向上.项目视图描述了产品所涉及的各个方面和在一个完

软件需求阅读笔记

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

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

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

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

读<需求工程--软甲建模与分析> 第五部分 需求管理与工程管理有感 在需求开发活动之后,需求基线应该成为后序软件系统开发的工作基础和粘合剂.需求管理在需求开发之后的产品生命周期中保证需求作用的有效发挥.作为需求开发的结果,最终的需求应该被明确和固定,需求基线就是被明确和固定的需求集合,是项目团队需要在,某一特定产品版本中实现的特征和需求集合.需求基线是需求开发过程中的成果总结,他需要在后续的产品生命周期中持续发挥作用.因此,需求基线要以一种持续.恒定和易于项目涉众访问的方式存在,通常的做法是将

软件需求分析阅读笔记

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

软件方法阅读笔记(一)

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

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

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

03实例化需求阅读笔记之三

这本书给出了做到实例化需求的关键过程模式: 从目标中获取范围--协作定制需求说明--举例说明--提炼需求说明--不需要修改需求说明的自动化验证--频繁验证--演化出一个文档系统. 从目标中获取范围:交付团队不应该指望用户直接给出范围或者解决方案,因为客户大部分时候并不具备提供良好需求的专业能力,且团队拥有的项目知识可能也被浪费了.因此需要帮助用户找出真正的目标,并通过协作共同界定项目范围. 分工是这样:用户提供需要的 功能以及开发软件的目的,团队根据用户给出的信息提出解决方案. 协作制定需求说明