《软件工程》课件第2章 软件要求定义_第1页
《软件工程》课件第2章 软件要求定义_第2页
《软件工程》课件第2章 软件要求定义_第3页
《软件工程》课件第2章 软件要求定义_第4页
《软件工程》课件第2章 软件要求定义_第5页
已阅读5页,还剩53页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

第2章软件要求定义

2.1可行性研究2.2项目开发计划2.3软件需求分析2.4IDEF方法2.5小结习题2.1可行性研究

2.1.1可行性研究的任务 首先需要进行概要的分析研究,初步确定项目的规模和目标,确定项目的约束和限制,把它们清楚地列举出来。然后,分析员进行简要的需求分析,抽象出该项目的逻辑结构,建立逻辑模型。从逻辑模型出发,经过压缩的设计,探索出若干种可供选择的主要解决办法,对每种解决方法都要研究它的可行性。可从以下三方面分析研究每种解决方法的可行性。

1.技术可行性 对要开发项目的功能、性能和限制条件进行分析,确定在现有的资源条件下,技术风险有多大,项目是否能实现,这些即为技术可行性研究的内容。这里的资源包括已有的或可以搞到的硬件、软件资源,现有技术人员的技术水平和已有的工作基础。 技术可行性常常是最难解决的方面,因为项目的目标、功能和性能比较模糊。技术可行性一般要考虑的情况包括:

(1)开发的风险:在给出的限制范围内,能否设计出系统并实现必须的功能和性能。 (2)资源的有效性:可用于开发的人员是否存在问题。可用于建立系统的其他资源是否具备。

(3)技术:相关技术的发展是否支持这个系统。 开发人员在评估技术可行性时,一旦估计错误,将会出现灾难性后果。

2.经济可行性 进行开发成本的估算以及了解取得效益的评估,确定要开发的项目是否值得投资开发,这些即为经济可行性研究的内容。 对于大多数系统,一般衡量经济上是否合算,应考虑一个“底线”,经济可行性研究范围较广,包括成本—效益分析、公司的长期经营策略、开发所需的成本和资源、潜在的市场前景。 3.社会可行性 研究要开发的项目是否存在任何侵犯、妨碍等责任问题,要开发项目的运行方式在用户组织内是否行得通,现有管理制度、人员素质和操作方式是否可行,这些即为社会可行性研究的内容。 社会可行性所涉及的范围也比较广,它包括合同、责任、侵权、用户组织的管理模式及规范,其他一些技术人员常常不了解的陷阱等。

2.1.2可行性研究的具体步骤 典型的可行性研究有下列步骤:

(1)确定项目规模和目标。分析员对有关人员进行调查访问,仔细阅读和分析有关的材料,对项目的规模和目标进行定义和确认,清晰地描述项目的一切限制和约束,确保分析员正在解决的问题确实是需要解决的问题。

(2)研究正在运行的系统。正在运行的系统可能是一个人工操作的系统,也可能是旧的计算机系统,因而需要开发一个新的计算机系统来代替现有系统。现有的系统是信息的重要来源。人们需要研究它的基本功能,存在什么问题,运行现有系统需要多少费用,对新系统有什么新的功能要求,新系统运行时能否减少使用费用等。

应该收集、研究和分析现有系统的文档资料,实地考察现有系统,在考察的基础上,访问有关人员,描绘现有系统的高层系统流程图(见2.1.3节),与有关人员一起审查该系统流程图是否正确。系统流程图反映了现有系统的基本功能和处理流程。

(3)建立新系统的高层逻辑模型。根据对现有系统的分析研究,逐渐明确新系统的功能、处理流程以及所受的约束,然后使用建立逻辑模型的工具——数据流图和数据字典(见8.3、8.4节)来描述数据在系统中的流动和处理情况。注意,现在还不是软件需求分析阶段,不是完整、详细的描述,只是概括地描述高层的数据处理和流动。 (4)导出和评价各种方案。分析员建立了新系统的高层逻辑模型之后,要从技术角度出发,提出实现高层逻辑模型的不同方案,即导出若干较高层次的物理解法。根据技术可行性、经济可行性和社会可行性对各种方案进行评估,去掉行不通的解法,就得到了可行的解法。

(5)推荐可行的方案。根据上述可行性研究的结果,决定该项目是否值得去开发。若值得开发,那么可行的解决方案是什么,并且说明该方案是可行的原因和理由。该项目是否值得开发的主要因素是从经济上看是否合算,这就要求分析员对推荐的可行方案进行成本—效益分析。 (6)编写可行性研究报告。将上述可行性研究过程的结果写成相应的文档,即可行性研究报告,提请用户和使用部门仔细审查,从而决定该项目是否进行开发,是否接受可行的实现方案。

2.1.3系统流程图

1.系统流程图的作用 系统流程图是描述物理系统的工具。所谓物理系统,就是一个具体实现的系统,也就是描述一个单位、组织的信息处理的具体实现的系统。在可行性研究中,可以通过画出系统流程图来了解要开发的项目的大概处理流程、范围和功能等。系统流程图不仅能用于可行性研究,还能用于需求分析阶段。

系统流程图可用图形符号来表示系统中的各个元素,例如,人工处理、数据处理、数据库、文件和设备等。它表达了系统中各个元素之间的信息流动的情况。 画系统流程图时,首先要搞清业务处理过程以及处理中的各个元素,同时要理解系统的流程图的各个符号的含义,选择相应的符号来代表系统中的各个元素。所画的系统流程图要反映出系统的处理流程。 在进行可行性研究过程中,要以概括的形式描述现有系统的高层逻辑模型,并通过概要的设计变成所建议系统的物理模型,可以用系统流程图来描述所建议系统的物理模型。 2.系统流程图的符号 系统流程图的符号如表2-1所示。表2-1系统流程图的符号 3.系统流程图的示例 下面以某工厂的库房管理为例,说明系统流程图的使用。 某工厂有一个库房,存放该厂生产需要的物品,库房中的各种物品的数量及各种物品库存量临界值等数据记录在库存文件上,当库房中物品数量有变化时,应更新库存文件。若某种物品的库存量少于库存临界值,则报告采购部门以便其订货,每天向采购部门送一份采购报告。

库房可使用一台微机处理更新库存文件和产生订货报告的任务。物品的发放和接收称为变更记录,由键盘录入到微机中。系统中的库存管理模块对变更记录进行处理,更新存储在磁盘上的库存文件,并把订货信息记录到联机存储中。每天由报告生成模块读一次订货信息,并打印出订货报告。图2.1给出了该系统的系统流程图。图2.1库存管理系统的系统流程图 2.1.4成本—效益分析 成本—效益分析的目的是从经济角度评价开发一个新的软件项目是否可行。成本—效益分析首先是估算将要开发的系统的开发成本,然后与可能取得效益进行比较和权衡。效益分有形效益和无形效益两种。有形效益可以用货币的时间价值、投资回收期和纯收入等指标进行度量;无形效益主要从性质上、心理上进行衡量,很难直接进行量的比较。系统的经济效益等于因使用新的系统而增加的收入加上使用新的系统可以节省的运行费用。运行费用包括操作人员人数、工作时间和消耗的物资等。下面主要介绍有形效益的分析。 F=P·(1+n·i) F就是P元在n年后的价值。反之,若n年后能收入F元,那么这些钱现在的价值为

P=F/(1+n·i)

例如,库房管理系统,它每天能产生一份订货报告。假定开发该系统共需5千元,系统建成后及时订货,消除物品短缺问题,估计每年能节约2.5千元,5年共节省12.5千元。假定年利率为5%,利用上面计算货币现在价值的公式,可以算出建立库房管理系统后,每年预计节省的费用的现在价值,如表2-2所示。表2-2将来的收入折算成现在值 2.投资回收期 通常用投资回收期衡量一个开发项目的价值。投资回收期就是使累计的经济效益等于最初的投资费用所需的时间。投资回收期越短,就越快获得利润,则该项目就越值得开发。 例如,库房管理系统两年后可以节省5.104千元,比最初的投资还多0.104千元。因此,投资回收期是2年。 投资回收期仅仅是一项经济指标,为了衡量一个开发项目的价值,还应考虑其他经济指标。 3.纯收入 衡量项目价值的另一个经济指标是项目的纯收入,也就是在整个生存周期之内的累计经济效益(折合成现在值)与投资之差。这相当于投资开发一个项目与把钱存入银行中进行比较,看这两种方案的优劣。若纯收入为零,则项目的预期效益和在银行存款一样,但是开发一个项目要冒风险,因此,从经济观点看这个项目,可能是不值得投资开发的。若纯收入小于零,那么这个项目显然不值得投资开发。 对上述的库房管理系统,项目纯收入预计为

10.911-5=5.911(千元) 2.1.5可行性研究的文档 可行性研究结束后要提交的文档是可行性研究报告。一个可行性研究报告的主要内容如下:

(1)引言:说明编写本文档的目的,项目的名称、背景,本文档用到的专门术语和参考资料。

(2)可行性研究前提:说明开发项目的功能、性能和基本要求,达到的目标,各种限制条件,可行性研究方法和决定可行性的主要因素。

(3)对现有系统的分析:说明现有系统的处理流程和数据流程、工作负荷、各项费用支出,所需各类专业技术人员和数量,所需各种设备,现有系统存在什么问题。 (4)所建议系统的技术可行性分析:对所建议系统的简要说明,处理流程和数据流程,与现有系统比较的优越性,采用所建议系统对用户的影响,对各种设备、现有软件、开发环境和运行环境的影响,对经费支出的影响,对技术可行性的评价。

(5)所建议系统的经济可行性分析:说明所建议系统的各种支出,各种效益,收益/投资比,投资回收周期。

(6)社会因素可行性分析:说明法律因素对合同责任、侵犯专利权和侵犯版权等问题的分析,说明用户使用可行性是否满足用户行政管理、工作制度和人员素质的要求。 (7)其他可供选择方案:逐一说明其他可供选择的方案,并说明未被推荐的理由。

(8)结论意见:说明项目是否能开发,还需什么条件才能开发,对项目目标有何变动等。2.2项目开发计划

经过可行性研究后,若一个项目是值得开发的,则接下来应制定项目开发计划。软件项目开发计划是软件工程中的一种管理性文档,主要是对开发的软件项目的费用、时间、进度、人员组织、硬件设备的配置、软件开发环境和运行环境的配置等进行说明和规划,是项目管理人员对项目进行管理的依据,据此对项目的费用、进度和资源进行控制和管理。

项目开发计划是一个管理性的文档,它的主要内容如下:

(1)项目概述:说明项目的各项主要工作;说明软件的功能、性能;为完成项目应具备的条件;用户及合同承包者承担的工作、完成期限及其他条件限制;应交付的程序名称,所使用的语言及存储形式;应交付的文档。

(2)实施计划:说明任务的划分,各项任务的责任人;说明项目开发进度,按阶段应完成的任务,用图表说明每项任务的开始时间和完成时间;说明项目的预算,各阶段的费用支出预算。

(3)人员组织及分工:说明开发该项目所需人员的类型、组成结构和数量等。

(4)交付期限:说明项目最后完工交付的日期。2.3软件需求分析 2.3.1需求分析的特点 在进行可行性研究和项目开发计划以后,如果确认开发一个新的软件系统是必要的而且是可能的,那么就可进入需求分析阶段。 需求分析是指开发人员要准确理解用户的要求,进行细致的调查分析,将用户非形式的需求陈述转化为完整的需求定义,再由需求定义转换到相应的形式功能规约(需求规格说明)的过程。需求分析虽处于软件开发过程的开始阶段,但它对于整个软件开发过程以及软件产品质量是至关重要的。

在计算机发展的早期,所求解问题的规模较小,需求分析被忽视。随着软件系统复杂性的提高及规模的扩大,需求分析在软件开发中所处的地位愈加突出,从而也愈加困难,它的难点主要体现在以下几个方面:

(1)问题的复杂性。这是由用户需求所涉及的因素繁多引起的,如运行环境和系统功能等。

(2)交流障碍。需求分析涉及人员较多,如软件系统用户、问题领域专家、需求工程师和项目管理员等,这些人具备不同的背景知识,处于不同的角度,扮演不同角色,造成了相互之间交流的困难。 (3)不完备性和不一致性:由于各种原因,用户对问题的陈述往往是不完备的,其各方面的需求还可能存在着矛盾,需求分析要消除其矛盾,形成完备及一致的定义。

(4)需求易变性。用户需求的变动是一个极为普遍的问题,即使是部分变动,也往往会影响到需求分析的全部,导致不一致性和不完备性。 为了克服上述困难,人们主要围绕着需求分析的方法及自动化工具(如CASE技术)等方面进行研究。 2.3.2需求分析的原则 近几年来已提出许多软件需求分析与说明的方法(如结构化分析方法和面向对象分析方法),每一种分析方法都有独特的观点和表示法,但都适用下面的基本原则:

(1)必须能够表达和理解问题的数据域和功能域。数据域包括数据流(即数据通过一个系统时的变化方式)、数据内容和数据结构,而功能域反映上述三方面的控制信息。

(2)可以把一个复杂问题按功能进行分解并可逐层细化。通常软件要处理的问题如果太大太复杂就很难理解,若划分成几部分,并确定各部分间的接口,就可完成整体功能。在需求分析过程中,软件领域中的数据、功能和行为都可以划分。 (3)建模。模型可以帮助分析人员更好地理解软件系统的信息、功能和行为,这些模型也是软件设计的基础。 结构化分析方法(见8.2节)和面向对象分析方法都遵循以上原则。

2.3.3需求分析的任务 需求分析的基本任务是要准确地定义新系统的目标,为了满足用户需要,回答系统必须“做什么”的问题。在可行性研究和项目开发计划阶段对这个问题的回答是概括的、粗略的。

1.问题识别 双方确定对问题的综合需求。这些需求包括:

(1)功能需求:指所开发的软件必须具备的功能,这是最重要的。

(2)性能需求:指待开发的软件的技术性能指标,如存储容量、运行时间等限制。 (3)环境需求:指软件运行时所需要的软、硬件(如机型、外设、操作系统和数据库管理系统等)的要求。

(4)用户界面需求:即人机交互方式、输入/输出数据格式等。 另外还有可靠性、安全性、保密性、可移植性和可维护性等方面的需求,这些需求一般通过双方交流、调查研究来获取,并达到共同的理解。 2.分析与综合,导出软件的逻辑模型 分析人员对获取的需求,进行一致性的分析检查,在分析、综合中逐步细化软件功能,划分成各个子功能。这里也包括对数据域进行分解,并分配到各个子功能上,以确定系统的构成及主要成分,并用图文结合的形式,建立起新系统的逻辑模型。

3.编写文档 编写文档的步骤如下:

(1)编写“需求说明书”,把双方共同的理解与分析结果用规范的方式描述出来,作为今后各项工作的基础。 (2)编写初步用户使用手册,着重反映被开发软件的用户功能界面和用户使用的具体要求,用户手册能强制分析人员从用户使用的观点考虑软件。

(3)编写确认测试计划,作为今后确认和验收的依据。

(4)修改完善项目开发计划。在需求分析阶段对开发的系统有了更进一步的了解,所以能更准确地估计开发成本、进度及资源要求,因此对原计划要进行适当修正。 2.3.4需求分析的方法 需求分析方法有功能分解方法、结构化分析方法、信息建模方法和面向对象分析方法等。

1.功能分解方法 功能分解方法是将一个系统看成是由若干功能构成的一个集合,每个功能又可划分成若干个加工(即子功能),一个加工又进一步分解成若干加工步骤(即子加工)。这样,功能分解方法有功能、子功能和功能接口三个组成要素。它的关键策略是利用已有的经验,对一个新系统预先设定加工和加工步骤,着眼点放在这个新系统需要进行什么样的加工上。

功能分解方法本质上是用过程抽象的观点来看待系统需求,是符合传统程序设计人员的思维特征,而且分解的结果一般已经是系统程序结构的一个雏形,实际上它已经很难与软件设计明确分离。 这种方法存在一些问题,它需要人工来完成从问题空间到功能和子功能的映射,即没有显式地将问题空间表现出来,也无法对表现的准确程度进行验证,而问题空间中的一些重要细节更是无法提示出来。功能分解方法缺乏对客观世界中相对稳定的实体结构进行描述,而基点放在相对不稳定的实体行为上,因此,基点是不稳定的,难以适应需求的变化。 2.结构化分析方法 结构化分析方法是一种从问题空间到某种表示的映射方法,由数据流图表示软件的功能,是结构化方法中重要的、被普遍接受的表示系统,它由数据流图和数据词典构成。这种方法简单实用,适于数据处理领域问题。

该方法对现实世界中的数据流进行分析,把数据流映射到分析结果中。但现实世界中的有些要求不是以数据流为主干的,就难于用此方法。如果分析是在现有系统的基础上进行的,应先除去原来物理上的特性,增加新的逻辑要求,再追加新的物理上的考虑。这时,分析面对的并不是问题空间本身,而是过去对问题空间的某一映射,在这种焦点已经错位的前提下,来进行分析显然是十分困难的。

该方法的一个难点是确定数据流之间的变换,而且数据词典的规模也是一个问题,它会引起所谓的“数据词典爆炸”,同时对数据结构的强调很少。

3.信息建模方法 信息建模方法是从数据的角度来对现实世界建立模型的,它对问题空间的认识是很有帮助的。 该方法的基本工具是ER图,其基本要素由实体、属性和联系构成。该方法的基本策略是从现实世界中找出实体,然后再用属性来描述这些实体。

信息模型和语义数据模型是紧密相关的,有时被看作是数据库模型。在信息模型中,实体E是一个对象或一组对象。实体把信息收集在其中,关系R是实体之间的联系或交互作用。有时在实体和关系之外,再加上属性。实体和关系形成一个网络,描述系统的信息状况,给出系统的信息模型。 信息建模和面向对象分析很接近,但仍有很大差距。在ER图中,数据不封闭,每个实体和它的属性的处理需求不是组合在同一实体中的,没有继承性和消息传递机制来支持模型。但ER图是面向对象分析的基础。 4.面向对象的分析 面向对象的分析是把ER图中的概念与面向对象程序设计语言中的主要概念结合在一起而形成的一种分析方法。在该方法中采用了实体、关系和属性等信息模型分析中的概念,同时采用了封闭、类结构和继承性等面向对象程序设计语言中的概念。

2.3.5需求分析的文档 需求说明书是需求分析阶段最重要的技术文档之一。它提供了用户与开发人员对开发软件的共同理解,其作用相当于用户与开发单位之间的技术合同,是今后各阶段设计工作的基础,也是本阶段评审和测试阶段确认与验收的依据。需求说明书的主要内容如下: (1)前言:说明项目的目的、范围,所用的术语的定义;用到的缩略语和缩写词;参考资料。

(2)项目概述:产品的描述;产品的功能;用户的特点;一般的约束等。

(3)具体需求:说明每个功能的输入、处理和输出;外部接口需求,包括用户接口、软件接口、硬件接口和通信接口;性能需求;设计约束;其他需求,包括数据库、操作等。2.4IDEF方法 2.4.1IDEF0的图形表示

IDEF0方法采用简单的图形符号和简洁的文字说明,描述系统在不同层次上的功能。在该方法中,将系统功能称为活动,将表示系统功能的图形称为活动图形。在活动图形中,用方框和箭头表示系统的各种活动及相互间的关系。图2.2表示了一个活动图形,其中“调整工资”即为活动,用主动的动词短语来描述。在系统分解的某一层次,可能有多个活动,为阅读方便,给每个活动编号,并注在方框的右下角。图2.2一个活动图形

连在方框上的箭头有4种类型:输入、输出、控制和机制。其中,输入指完成某项活动所需的数据,用连在方框左边的箭头表示;输出指执行活动时产生的数据,用连在方框右边的箭头表示;控制指活动所受到的约束条件,用连在方框上边的箭头表示;机制指活动是由谁来完成的,它可以是人、组织、设备及其他系统等,用连在方框下边的箭头表示。 有时,输入与控制的意义不易区别,一般情况下输入是活动要“消化掉”或“变换成输出”的数据,而控制只是说明由输入变换到输出的条件,当无法区分时可将输入看作控制。一个活动可无输入,但必须至少有一个控制。 2.4.2建立功能模型的基本方法

1.建模基本方法 建立功能模型的基本方法有4步。

1)确定建模的范围、观点及目的 在开始为系统建立模型时,首先要确定建模的立足点,包括范围、观点及目的。范围指所讨论的对象是什么,它的边界和外部接口是什么;观点指从什么角度去考虑所研究的问题;目的指确定所研究问题的意图及理由。 2)建立系统的内外关系图——A-0图

IDEF0方法建立的功能模型是一组有层次关系的图形,用字母A开头的编号来标志图形在层次中的位置。先建立系统的内外关系图,该图用来抽象地描述所研究的问题及其边界或数据接口。图中只有一个活动,活动名概括地描述系统的内容,用进入和离开的箭头表示系统与环境的数据接口,确定了系统边界。

3)建立顶层图——A0图 把A-0图分解为3~6个主要部分便得到A0图,它清楚地表达了A-0图在同样信息范围内的细节,从结构上反映了模型的观点,是系统功能模型真正的顶层图。该图中各方框所表示活动的详细含义由低层次的图形说明。 4)建立低层次的图形 按照自顶向下的方法,从A0图开始逐层分解,建立一系列的活动图形,直到最低层为止。分解时,应遵循两条原则:首先,保持在同一水平上分解(即宽度优先),如A1,A2,A3等图,而不是A1,A11,A111(后者为深度优先),这样,可避免较高层次的变化影响较低层次,造成可能的重复工作,同时可较早地查出错误及遗漏;其次,对于同一水平层次上的各个方框,选择难度最大的部分往下分解,其后分解较容易的部分。 在IDEF0图中几个活动之间无明确的顺序和时间,要注意逐层分解时箭头表示的上、下层之间的平衡关系,即保持了图的边界箭头与父图箭头一致。 2.IDEF方法应用示例 现以某企业销售管理系统为例,说明IDEF方法的应用。 企业销售管理的描述如下:

(1)接受顾客的订单,检验订单。若库存有货,则进行供货处理,即修改库存,给仓库开备货单,并且将订单留底;若库存量不足,则将缺货订单登入缺货记录。

(2)根据缺货记录进行缺货处理,将缺货通知单发给采购部门,以便采购。

(3)根据采购部门发来的进货通知单处理进货,即修改库存,并从缺货记录中取出缺货订单进行供货处理。

(4)根据留底的订单进行销售统计,打印统计表给经理。

图2

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论