第02章 软件需求分析.docx
- 文档编号:4331230
- 上传时间:2022-11-29
- 格式:DOCX
- 页数:20
- 大小:253.77KB
第02章 软件需求分析.docx
《第02章 软件需求分析.docx》由会员分享,可在线阅读,更多相关《第02章 软件需求分析.docx(20页珍藏版)》请在冰豆网上搜索。
第02章软件需求分析
第二章软件需求分析
要开发高质量的软件,很大程度上取决于对要解决的问题的认识以及如何准确地表达出用户的需求。
从而做到对系统有深刻地理解和认识,并将其规范化、理论化,同时起到沟通用户和开发者的作用,为后续工作提供依据。
为达到该目的,拟采用各种技术、方法和手段,最终以文档的形式表现出来。
本章首先介绍需求分析的一些基本概念,然后,分别对需求获取技术、需求规格说明书、如何进行需求分析以及需求分析方法进行讨论。
2.1需求分析的任务
2.1.1基本原理
需求分析的任务就是完全弄清用户(顾客)对软件系统的确切要求,用规范的格式表达出来。
也可以说,需求分析的任务就是给出一个将要用软件来解决的一个问题的初始定义。
根据IEEE软件工程标准词汇表(1997)年中对需求的描述为:
●用户解决问题或达到目的所需的条件或权能(Capability)。
●系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或权能。
●一种能反映上面
(1)或
(2)所描述的条件或权能的文档说明。
用规范的格式表达出来的需求说明称之为需求规格说明书,或者简称为“需求说明”。
“需求说明”应该具有准确性和一致性。
因为它是连接计划时期和开发时期的桥梁,也是软件设计的依据。
任何含混不清、前后矛盾、或者一个微小的错漏,都可能导致误解或铸成系统的大错,在纠正时付出巨大的代价。
“需求说明”应该是具有清晰性和没有二义性。
因为它是沟通用户和系统分析员思想的媒介,双方要用它来表达对于需要计算机解决的问题的共同的理解。
如果在需求说明中使用了用户不易理解的专门的术语,或用户与分析员对要求的内容可以做出不同的解释,便可能导致系统的失败。
“需求说明”应该直观、易读和易于修改。
为此应尽量采用标准的图形、表格和简单的符号来表示,使不熟悉计算机的用户也能一目了然。
2.1.2需求的层次
软件需求一般包含三个层次──业务需求、用户需求和功能需求──还包括非功能需求。
软件需求各组成部分之间的关系如图2-1所示。
业务需求(businessrequirement):
反映了组织机构或客户对系统、产品高层次的目标要求,它们在项目视图与范围文档中予以说明。
用户需求(userrequirement):
描述了用户使用产品必须要完成的任务和具备的功能,这在使用实例(usecase)文档或方案脚本(scenario)说明中予以说明。
功能需求(functionalrequirement):
定义了开发人员必须实现的软件功能,使得用户能完成他们的任务,从而满足其业务需求。
在软件需求规格说明书(softwarerequirementsspecification,SRS)中对上述三个需求层次进行详细描述。
软件需求规格说明中说明的功能需求充分描述了软件系统所应具有的外部行为。
软件需求规格说明在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。
作为功能需求的补充,软件需求规格说明书还应包括非功能需求.它描述了系统展现给用户的行为和执行的操作等。
它包括产品必须遵从的标准、规范和合约,外部界面的具体细节,性能要求,设计或实现的约束条件及质量属性等。
图2-1软件需求各组成部分的关系
2.1.3需求的开发与管理
我们可以将整个软件需求工程研究领域划分为需求开发和需求管理两部分,如图2-2所示:
图2-2需求工程域的层次分解示意图
需求开发可进一步分为:
问题获取(elicitation)、分析(analysis)、编写规格说明(specification)和验证(verification)四个阶段(ThayerandDorfman1997)。
这些子项包括软件类产品中需求收集、评价、编写文档等所有活动。
需求开发活动包括以下几个方面:
·确定产品所期望的用户类。
·获取每个用户类的需求。
·了解实际用户任务和目标以及这些任务所支持的业务需求。
·分析源于用户的信息。
·将系统级的需求分为几个子系统,并将需求中的一部份分配给软件组件。
·了解相关质量属性的重要性。
·商讨实施优先级的划分。
·将所收集的用户需求编写成规格说明和模型。
·评审需求规格说明,确保对用户需求达到共同的理解与认识,并在整个开发小组接受说明之前将问题都弄清楚。
需求管理需要建立并维护在软件工程中同客户达成的契约。
这种契约都包含在编写的需求规格说明与模型中。
客户的接受仅是需求成功的一半,开发人员也必须能够接受他们,并真正把需求应用到产品中。
通常的需求管理活动包括:
·定义需求基线(迅速制定需求文档的主体)。
·评审提出的需求变更、评估每项变更的可能影响从而决定是否实施它。
·以一种可控制的方式将需求变更融入到项目中。
·使当前的项目计划与需求一致。
·估计变更需求所产生影响并在此基础上协商新的承诺(约定)。
·让每项需求都能与其对应的设计、源代码和测试用例联系起来以实现跟踪。
·在整个项目过程中跟踪需求状态及其变更情况。
由图2-3中可以从另一个角度来看需求开发和需求管理之间的区别:
下一步:
·记录下当前项目或以前项目中所遇到的与需求相关的问题。
指明每一个问题是需
图2-3需求开发与需求管理之间的界限
求开发问题还是需求管理问题,以及这些问题带来的影响及其产生的根本原因。
·与项目组成员和其他风险承担者(客户,市场调查人员,项目管理者)一起讨论当前或以前项目中的需求问题,及其产生的根源和带来的影响。
向所有参与者指明,如果想解决这些困难,必须正视它,大家是否为此做好准备了呢?
·整理出对整个项目人员一天训练用的软件需求课程,人员要包括重要的客户,市场人员和管理人员。
训练是一种有效的团队学习与合作的方法。
大家将会在训练中达成术语与技术上的共识,有利于相互交流沟通与协作。
2.2需求获取的技术
所谓需求是指用户对软件的功能和性能的要求,就是用户希望软件能做什么事情,完成什么样的功能,达到什么性能。
对于软件开发人员首先要解决的问题是:
怎样获取这些需求、并且整理和组织好有关需求文档,以符合行业的规范进行表达。
2.2.1人员的组成
一般的说,需求分析小组的人员,也就是参与需求分析的工作人员由两方面组成,一方面是熟悉软件开发工作的、参与软件需求分析的专业技术人员,也就是人们常说的系统分析员,另一方面就是用户(或者是顾客),两方人员缺一不可。
需求工作的好坏、成败与否直接和双方人员的合作程度、素质、工作经验等因数有关。
2.2.2需求分析人员的组成
由软件开发过程中错误的放大效应知,最初的错误可能导致最终整个项目的失败,所以,前期的需求工作非常重要,往往不仅仅受到技术的要求,还要考虑许多有关政策、法规等因数的影响。
所以,一个好的需求分析工作应该由用户和开发方的较高层次的人员共同完成。
一般的做法是:
系统分析小组由系统分析员作为组织者,系统分析员应该掌握尽可能多的需求分析技术和经验,需求分析工作是否能够顺利的开展,系统分析员负有直接的主要的责任,由系统分析员作为需求分析的组织者,和用户结合起来共同分析软件需求,这样他们就可以发挥他们各自的优势。
其中还需要双方各自补充学习对方领域的知识,这一点也很重要,否则,他们互相间由于对对方的领域的知识了解不足,也会造成沟通的困难,难于共同讨论软件需求,在需求分析过程中双方的沟通是最重要的一个因素。
2.2.3需求的类型
通常需求分为两种类型:
一种是功能性需求,一种是非功能性需求,这一点也需要有一种清楚的认识。
功能性需求是指需要计算机系统解决的问题,也就是对数据的处理要求,这是一类最主要的需求。
非功能性需求是指实际使用环境所要求的需求,往往是一些限制要求,例如:
性能要求,可靠性要求,安全保密要求,等等。
虽然说非功能性需求是一些相对次要的需求,但是也是不可忽略的。
2.2.4获取需求的途径
总的来说,需求分析小组内的充分交流是获取需求的主要途径。
在需求获取过程中,有如下一些具体的交流方式。
1.互相学习:
开发方向用户介绍有关计算机的知识,用户代表向开发方介绍软件应用领域的知识。
可以采用专题介绍的方式进行。
2.实地考察:
双方互相实地考察,以使各方增加对对方的领域的感性认识。
3.收集相关资料:
双方积极充分的收集有关问题的解决的资料。
4.语言交流:
这是一种最原始的交流方式,也是采用得最多的一种方式,这里要强调的是单纯的语言交流有很多的弊病,语言文字具有二义性,可能会造成双方的曲解,此外,语言也不便于表达复杂的逻辑。
5.图形表格工具:
这是避免语言文字交流的弊病的一个好的方法。
6.时间表:
在需求分析过程中要安排好实施计划。
2.3需求规格说明书
2.3.1需求说明的目的
在仔细分析和理解了用户的需求之后,还需要对需求进行清楚的表达,形成规范的需求规格说明书。
表达需求的主要目的为:
1.为了方便需求分析小组共同讨论软件需求,一种好的清楚的表达方式可以更加进一步的增进对需求的理解。
2.作为下一步软件设计的基础,在软件开发的其后各个阶段的工作都是以这一阶段的成果──需求规格说明书──作为基础的,如果这一阶段的工作没有做好,或者是需求理解的错误,或者是需求表达的不足,都会给其后的工作带来灾难。
3.作为软件测试的根据,在后面的软件测试阶段,需要测试所设计实现的软件是否满足了需求说明书的要求。
所以规范的表达需求是必须的,需求分析的双方要学习掌握一些清楚规范的表达需求的技术和方式。
2.3.2需求说明的方法
一般来说,在进行需求说明工作过程中,往往采取自上而下、由粗到细、多次循环、逐步完善的方法。
即,我们先在最高层次上表达系统的总体需求,然后,逐步分层次向下进行细化和完善。
在最初的时候,需求是以用户的自然语言(使用正常的句子或词组)来指定的。
然而仅使用自然语言来表示需求会产生一些问题,众所周知,自然语言具有二义性,不适合表达一些复杂的数据及其处理规则,就像计算机算法很少使用自然语言来表示的那样,通常算法使用形式化的图表和语言,需求也需要一种形式化的没有二义性的表达方式,因此,软件工程师研究了许多方式来定义需求的方法。
通常采用形式符号来描述将要建立的系统,用自然语言加以辅助。
这种方法的一个优势就是容易开发出一些工具来检查需求规格的完全性和一致性,并更加容易跟踪管理。
特别需要强调说明的是,这种使用图表和形式语言表达的需求是用户和开发人员沟通的桥梁,见图2-4,一定要用户和开发人员都能够清楚的认识并理解这种表达方式所包含的确切的含义。
也就是说这种表达方式不仅是面向问题的,它同时应该是面向计算机的。
图2-4用户、需求说明、系统分析员之间的关系
一般情况下,采用哪种表达方式是由开发人员选定的,所以开发人员要注意的是,不能只考虑自己的方便,而只选用自己熟悉的面向计算机专业的表达方式,忽略了用户的理解程度。
从本质上说,这种表达需求的方式应该是用于描述问题的,而和计算机处理方式没有关系,所以不应选用面向计算机处理的表达方式,因为这种方式用户不易理解和掌握,而且,这种表达方式本身也脱离了需求说明的本意――即对问题本身的需求的分析。
在这些形式化的表达方式方法中,最具典型的方法是数据流图和数据词典。
2.3.3数据流图
数据流图(DFD,DataFlowDiagram)是一种描述软件系统逻辑模型的图形符号,图中描述了数据(信息)在系统中的流动变化情况,这种图形表示既可以从本质上描述计算机软件系统的工作情况,又适合非计算机专业人员学习和掌握,在需求分析中是一种很好的交流和表达工具。
图中包含有四种基本的图形符号,见图2-5
除了上面介绍的四种基本图形符号外还有一些“*”(表示与),“+”(表示或)等辅助图形符号,见图2-6
图2-6DFD的附加符号
在数据流图中每一个图形符号都必须标上名字,加工还应该标上序号,以便于在后面的数据词典中进一步描述说明。
例如,图2-7表示一个高度抽象了的软件系统的模型。
图2-7高度抽象的软件模型
在分析表达数据流图时还应该在概念上特别注意几点:
1.数据流图只是表达系统中(信息)数据的流动,是一种软件系统信息处理的逻辑模型,在图中不包括任何实际的物理实体。
2.带箭头的线表示的是数据的流动,而不是实物流或者控制流,和计算机算法描述的流程图中的流程线也是不同的。
3.在数据流图中没有算法描述中常出现的那种循环和分支,因为数据流图只是在描述要解决的问题本身“是什么”,而不用考虑“怎么做”。
2.3.4数据词典和加工说明
数据词典(DD,DataDictionary)是用来描述系统中所涉及的每一个数据,它是一个数据描述的集合,也有人把数据词典称为“数据的数据”,通常和数据流图配合使用,用来描述数据流图中所出现的各种数据和加工,也就是为数据流图中所出现的各种成份编排词典加以进一步说明,也有人将对加工的说明另外组成一个加工说明集合,就又形成了加工说明。
在数据词典中,用数据项、数据流和数据文件来对数据进行描述:
数据项也称为数据元素,是表达有效信息的最基本单位。
数据流由相关数据项组成数据流。
数据文件表示对数据的存储(外部存储器),由若干数据项按照一定的组织方式组成。
在数据词典中每一个词典条目的参考格式如表2-1:
在词典条目中,对每一个数据类型设置了“别名”,因为不同的用户对同一数据可能有不同的称呼,这样同一数据的不同别名在数据词典上得到了统一,通过这种方式实现了准确性和一致性。
为了使定义简明,在数据词典中可以使用一些关系符号,如表:
符号
含义
=
等于,定义为
+
加
[]
选择符,表示对[]中列举的值可以任取其一
{}
重复符,表示对{}中的内容可视需要重复使用
()
可选符,表示对()中的内容可由设计员决定取舍
*…,..*
注释符,表示两个*号之间的内容为对条目的注释
表2-2数据词典中使用的关系符号
例如:
学生成绩信息=学号+姓名+{课程名+成绩}+总评分
定义一个数据词典来说明数据流图中的各种成份的是重要的,它和数据流图配合起来将是软件开发后续阶段,开发人员的重要依据。
2.3.5需求规格说明书格式
需求分析工作完成的一个基本标志是形成了一份完整、规范的需求规格说明书(需求分析报告),一般来说,一份完整规范的需求规格说明书应包含下面的一些内容。
引言:
对系统进行一些概要的描述;
引用标准:
给出本需求规格说明书的有关参考标准;
系统及任务描述:
用以描述系统中各种实体及其相应的关系,通常可用实体关系图和层次方框图来描述。
需求规定:
对系统的功能、性能、精度以及输入、输出等具体要求作出规定。
数据描述:
描述逻辑数据模型,也就是各种数据关系和相应的处理,通常可以使用数据流图,数据词典,加工说明来描述。
功能描述:
用以描述要解决的各种问题。
性能描述:
描述系统性能方面的内容。
质量保证:
描述系统各部分要求达到的质量标准。
其他:
描述其他的一些补充内容。
签字认证:
用户和开发人员双方签字认证。
2.4需求分析的过程
2.4.1抽取现实问题的本质
需求分析的过程可以说是一个对具体问题的反复理解和抽象的过程,理解就是对现实问题的理解,要弄清楚究竟需要解决什么问题,抽象就是除去问题的表面,提取问题的本质,建立问题的逻辑模型,以便于以后阶段的系统的设计实现。
在现实环境中人们有很多针对数据的加工处理方法,计算机软件的功能就是对数据(信息的表达)的加工(信息的处理),计算机能解决和数据加工、处理有关的问题。
由于在现实环境中人们对数据的加工处理方法和在计算机系统中对数据的加工处理方法在形式上是是不同的,所以就有一个数据和对数据的加工处理方法在形式上进行转换的问题,要从一种形式转换为另一种形式。
要抽取现实问题的本质,然后以抽取的现实问题的本质作为基础,设计一种可以由计算机来实现和处理的方法,只有这样才能保证两种不同的处理形式表达的是同一个处理内容,见图2-8,所以需求分析的实质就是要分析现实问题中有什么数据,需要什么样的加工处理,并且抽象出问题的本质――逻辑模型。
如果用“数据结构”(计算机专业的一门课程)原理的概念来描述的话,那就是要抽象出问题的数据关系和对数据的加工处理(问题的抽象数据模型),以便于后续阶段计算机系统解决方案的设计与实现。
图2-8针对同一问题的不同形式的处理方法
例如,要开发一个学生教材管理系统,对于这个问题,现实的处理方法可能是:
学生先到系办公室的李秘书开一个证明,凭证明去找教材科的吴会计,由吴会计开具购书发票,然后向黄出纳交付书款,最后到书库找赵管理员取书。
图2-9描述了针对上述案例的一个实际的处理方法。
图2-9学生购书实际处理流程
去掉现实处理方法中非本质的因素,可以抽象出一个学生教材管理的逻辑模型,如图2-10所示:
图2-10学生教材管理的逻辑模型
2.4.2改进和优化
通常的做法是通过对现实环境的调查研究,获得要解决的问题的一个当前系统的具体模型(系统流程图),然后去掉具体模型中的非本质因素,抽象出当前系统的逻辑模型(数据流程图),由于在现实环境中对问题的解决方式和在计算机系统中对问题的解决方式的不同,有些内容在现实环境中可以实现而在目前的计算机环境中不可能实现,或者,有些有益的内容在现实环境中不能实现而在计算机系统中可以方便的实现,所以需要不断的对现有的逻辑模型进行改进和优化,最后得到目标系统的逻辑模型,见图2-11。
图2-11需求分析的过程
例如,上述教材系统中,“有效性审查”和“开发票”在计算机系统中可以合而为一,如图2-12:
图2-12优化后的学生教材管理逻辑模型
2.4.3需求分析的验证
需求分析过程中除了上述工作外,还有一个重要的内容就是要反复验证需求分析过程中所得出需求的正确性。
需求不仅描述了进出系统的信息流和系统所进行的数据转换,而且也描述了对系统运行所施加的限制。
因此,需求分析通常有三个目标。
首先,是表明了系统开发人员对用户系统需求的理解,其次,告诉设计开发人员所开发的系统将具备的功能和待点。
第三,需求告诉测试人员怎样验证以使用户确信所交付的系统的确是要求的系统。
需求分析的结果是否正确是非常重要的,为确保系统分析员和用户之间都能正确理解需求,通常要在下面几个方面验证:
1、需求是正确的吗?
开发人员和用户都应复查它们,以确保它们将用户的需要充分、正确地被表达了出来。
2、需求是一致的吗?
也就是说,有没有任何冲突或含糊的需求?
例如,一条需求说明表述本系统在某一个时间里最多只能有10个使用者;而另外一条需求说明表述本系统在某条件下可能有20名使用者,这就造成了需求是不一致性。
换句话说,如果两条需求不能同时满足,则说二者是不一致的。
3、需求是完全的吗?
如果所有可能的状态、状态变化、转入、产品和约束都在需求中作了描述了,那么说这个需求集合是完全的。
4、需求是实际可行的吗?
系统真的能做顾客所请求做的事吗?
例如,假定一个系统请求用户存取位于几千里外的主计算机,并且对远程用户的响应时间要和对本地用户的响应时间相同。
这种需求就有可能是不实际的,因为通信线路上的传输需要额外的时间。
5、每一条需求所描述的事物是顾客需要的吗?
我们应该复查需求来确定哪些需求直接与顾客的问题有关。
6、需求是可检验的吗?
我们必须能写出测试用例来验证是否满足了需求。
7、需求是可跟踪的吗?
每一系统功能都能被跟踪到要求它的需求集合吗?
容易找到处理一个系统特定方面的需求集合吗?
利用上面提到的内容仔细审查(复审)每个可能的需求,采用这种方式对目标系统的逻辑模型进行完善和补充。
最后按照约定的格式写出规范完整的需求说明书。
作为需求分析阶段最后一项工作,也是常常被忽略但却是重要的一项工作,就是双方或者三方的复审后的签字,作为软件开发合同的组成内容,签字后,如果在后续的开发过程中要更改,双方要重新协商,达成协议后再更改。
人们在软件的开发实践中逐步总结和发明了一些完成需求分析过程的方法,这些方法的目标是共同的,但是在具体的做法上各有不同,也各有优缺点,在实际中我们可以仿照实施,但是也不必拘泥于方法本身,要结合具体问题的特点,适当选择不同的需求分析方法,或者是需求分析方法中的有关步骤。
经过开发人员多年的实践逐步总结出了一些有效的方法,比较著名的有结构化软件需求分析方法,原型化需求分析方法,还有面向对象的需求分析方法,等等,在下面的章节中,将陆续选取介绍。
2.5结构化需求分析方法
结构化分析方法最初由DouglasRoss提出,由DeMarco推广,由Ward和Melior以及后来的Hatley和Pirbhai扩充,形成了当今的结构化分析方法的框架。
结构化需求分析方法(SA,StructuredAnalysis)是一种面向数据流的自顶向下逐步求精的分析方法,按照T.DeMarco的定义,“结构化就是使用DFD、DD、结构化英语、判定表和判定树等工具,来建立一种新的、称为结构化说明书(structuredspecification)的目标文档”,上面的结构化说明书也就是需求规格说明书,也有人称之为软件需求说明书(SRS,SoftwareRequirementSpecification)。
这种需求分析方法,把目光集中在针对数据流的分析上,分析初始有哪些数据,对这些数据又经过了哪些加工,加工后又变为什么数据流,最近又得到什么样的结果数据流。
这种分析方法抓住了信息处理的本质――即数据及其处理,通过这样的分析可以将要解决的问题清清楚楚的展现出来。
结构化需求分析方法主要由三个步骤组成。
2.5.1画分层数据流图
一个较为复杂的软件系统,往往包含了成百上千的数据和加工,很难一次就把它们完全弄清楚,画分层数据流图使用了一种人们通常处理复杂问题的一种方法,就是“自顶向下,逐步细化”(top-downstepwiserefinement),其核心就是逐步分解,先把系统看成是一个整体,然后从系统的最上层开始逐层分解,每做一次分解,系统的加工数量就会增加同时加工的内容也逐步具体简单,直到所有的加工都足够简单为止。
例如,有这样一个问题:
在要建立的学生管理系统中,由学管科负责录入、修改、删除学生信息(学号、姓名);体检科负责录入学生健康信息(学号、健康情况),其中健康状况分为:
优、良、一般、差;学籍科负责录入学生成绩。
学生处领导可随时查询学生基本信息,各类健康状况的百分比,平均成绩以及不及格的人数。
可以画出分层的数据流图如下:
顶层:
0层:
1层:
图2-13分层的数据流图
最后就得到一种分层的数据流图,很显然,这种分层分析需求的方法,是一种有效的需求分析技术。
2.5.2确定数据定义和加工策略
数据流图描述了系统中数据的流动和变化,在得到了数据流动和变化图后,需要确定每一个数据流和变化(加工)的细节,也就是数据词典和加工词典,这是一个很重要的步骤,是软件开发后续阶段的工作的基础,如图表,
数据字典:
(1)、数据流条目:
学生基本信息:
学号+姓名
学生健康信息:
学号+健康情况
学生成绩:
学号+平均成绩
查询要求:
[健康查询单|平均成绩查询单|不及格人数查询]
学生健康情况表:
优%+良%+一般%+差%
学生成绩单:
学号+姓名+平均成绩
不及格人数统计表:
学号+成绩+不及格总人数
(2)、文件条目:
文件名:
基本信息文件
组成:
{学号+姓名+入学成绩+生源}
组织:
按学号递增顺序排列
文件名:
健康文件
组成:
{学号+姓名+健康情况}
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 第02章 软件需求分析 02 软件 需求 分析