软件要求定义

1、 2.1 可行性研究 2.2 项目开发计划 2.3 软件需求分析 2.4 IDEF方法第 2 章 软件要求定义返回主目录第 2 章 软件要求定义 2.1 可行性研究 2.1.1 可行性研究的任务 首先需要进行概要的分析研究，初步确定项目的规模和目标，确定项目的约束和限制，把它们清楚地列举出来。然后， 分析员进行简要的需求分析，抽象出该项目的逻辑结构，建立逻辑模型。从逻辑模型出发，经过压缩的设计，探索出若干种可供选择的主要解决办法，对每种解决方法都要研究它的可行性。可从以下三方面分析研究每种解决方法的可行性。 1. 技术可行性 对要开发项目的功能、 性能和限制条件进行分析， 确定在现有的资源条件

2、下，技术风险有多大，项目是否能实现，这些即为技术可行性研究的内容。这里的资源包括已有的或可以搞到的硬件、软件资源，现有技术人员的技术水平和已有的工作基础。 技术可行性常常是最难解决的方法，因为项目的目标、功能和性能比较模糊。技术可行性一般要考虑的情况包括： (1) 开发的风险： 在给出的限制范围内， 能否设计出系统并实现必须的功能和性能? (2) 资源的有效性： 可用于开发的人员是否存在问题? 可用于建立系统的其他资源是否具备? (3) 技术： 相关技术的发展是否支持这个系统? 开发人员在评估技术可行性时， 一旦估计错误， 将会出现灾难性后果。 2. 经济可行性 进行开发成本的估算以及了解取得

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

4、究有下列步骤： (1) 确定项目规模和目标。分析员对有关人员进行调查访问，仔细阅读和分析有关的材料，对项目的规模和目标进行定义和确认，清晰地描述项目的一切限制和约束，确保分析员正在解决的问题确实是要解决的问题。 (2) 研究正在运行的系统。正在运行的系统可能是一个人工操作的系统，也可能是旧的计算机系统，因而需要开发一个新的计算机系统来代替现有系统。现有的系统是信息的重要来源。人们需要研究它的基本功能，存在什么问题，运行现有系统需要多少费用，对新系统有什么新的功能要求，新系统运行时能否关不管使用费用等。 应该收集、研究和分析现有系统的文档资料，实地考察现有系统，在考察的基础上，访问有关人员，然后

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

6、行性对各种方案进行评估， 去掉行不的解法，就得到了可行的解法。 (5) 推荐可行的方案。根据上述可行性研究的结果， 应该决定该项目是否值得去开发。 若值得开发，那么可行的解决方案是什么，并且说明该方案是可行的原因和理由。该项目是否值得开发的主要因素是从经济上看是否合算，这就要求分析员对推荐的可行方案进行成本效益分析。 (6) 编写可行性研究报告。将上述可行性研究过程的结果写成相应的文档，即可行性研究报告，提请用户和使用部门仔细审查，从而决定该项目是否进行开发，是否接受可行的实现方案。 系统流程图 1. 系统流程图的作用 系统流程图是描述物理系统的工具。所谓物理系统，就是一个具体实现的系统，也就

7、是描述一个单位、组织的信息处理的具体实现的系统。在可行性研究中，可以通过画出系统流程图来了解要开发的项目的大概处理流程、 范围和功能等。 系统流程图不仅能用于可行性研究，还能用于需求分析阶段。 系统流程图可用图形符号来表示系统中的各个元素， 例如，人工处理、数据处理、数据库、文件和设备等。它表达了系统中各个元素之间的信息流动的情况。 画系统流程图时，首先要搞清业务处理过程以及处理中的各个元素，同时要理解系统的流程图的各个符号的含义， 选择相应的符号来代表系统中的各个元素。所画的系统流程图要反映出系统的处理流程。 在进行可行性研究过程中，要以概括的形式描述现有系统的高层逻辑模型，并通过概要的设计

8、变成所建议系统的物理模型， 可以用系统流程图来描述所建议系统的物理模型。 2. 系统流程图的符号 系统流程图的符号如表 2 - 1 所示。 3. 系统流程图的示例 下面以某工厂的库房管理为例， 说明系统流程图的使用。 某工厂有一个库房， 存放该厂生产需要的物品， 库房中的各种物品的数量及各种物品库存量临界值等数据记录在库存文件上，当库房中物品数量有变化时，应更新库存文件。若某种物品的库存量少于库存临界值，则报告采购部门以便其订货， 每天向采购部门送一份采购报告。 库房可使用一台微机处理更新库存文件和产生订货报告的任务。物品的发放和接受称为变更记录，由键盘录入到微机中。 系统中的库存管理模块对变

9、更记录进行处理，更新存储在磁盘上的库存文件，并把订货信息记录到联机存储中。每天由报告生成模块读一次订货信息，并打印出订货报告。图 2.1 给出了该系统的系统流程图。 图 2.1 库存管理系统的系统流程图 2.1.4 成本效益分析 成本效益分析的目的是从经济角度评价开发一个新的软件项目是否可行。成本一效益分析首先是估算将要开发的系统的开发成本，然后与可能取得效益进行比较和权衡。效益分有形效益和无形效益两种。有形效益可以用货币的时间价值、 投资回收期和纯收入等指标进行度量；无形效益主要从性质上、 心理上进行衡量，很难直接进行量的比较。系统的经济效益等于因使用新的系统而增加的收入加上使用新的系统可以

10、节省的运行费用。运行费用包括操作人员人数、工作时间和消耗的物资等。下面主要介绍有形效益的分析。 1. 货币的时间价值 成本估算的目的是对项目投资。经过成本估算后， 得到项目开发时需要的费用，该费用就是项目的投资(成本估算的方法见节)。 项目开发后，应取得相应的效益，有多少效益才合算? 这就是考虑货币的时间价值。通常用利率表示货币的时间价值。 设利率为i, 现存放P元，n年后可得钱数为F，若不计复利， 则 F=P(1+ni)F就是P元在n年后的价值。反之，若n年后能收入F元， 那么这些钱现在的价值为 P=F/(1+ni) 例如， 库房管理系统，它每天能产生一份订货报告。 假定开发该系统共需5千元

11、，系统建成后及时订货，消除物品短缺问题，估计每年能节约千元，5年共节省千元。假定年利率为5%，利用上面计算货币现在价值的公式， 可以算出建立库房管理系统皇，每年预计节省的费用的现在价值， 如表 2 - 2 所示。 表 2 2 将来的收入折算成现在值 年将来值/千元（1+n.0.05)现在值/千元累计的现在值/千元123452.52.52.52.52.51.051.11.151.21.252.3812.2732.1742.0832.02.3814.6546.8289.36111.361 2. 投资回收期 通常用投资回收期衡量一个开发项目的价值。投资回收期就是使累计的经济效益等于最初的投资费用所需

12、的时间。 投资回收期越短，就越快获得利润，则该项目就越值昨开发。 例如，库房管理系统两年后可以节省千元， 比最初的投资还多千元。因此， 投资回收期是 2 年。 投资回收期仅仅是一项经济指标，为了衡量一个开发项目的价值，还应考虑其他经济指标。 3. 纯收入 衡量项目价值的另一个经济指标是项目的纯收入，也就是在整个生存周期之内的累计经济效益(折合成现在值)与投资之差。 这相当于投资开发一个项目与把钱存入银行中进行比较， 看这两种方案的优劣。若纯收入为零，则项目的预期效益和在银行存款一样，但是开发一个项目要冒风险，因此，从经济观点看这个项目，可能是不值得投资开发的。若纯收入小于零， 那么这个项目显然

13、不值得投资开发。 对上述的库房管理系统， 项目纯收入预计为 11.361-5=6.361(千元) 2.1.5 可行性研究的文档 可行性研究结束后要提交的文档是可行性研究报告。一个可行笥研究报告的主要内容如下： (1) 引言： 说明编写本文档的目的， 项目的名称、 背景， 本文档用到的专门术语和参考资料。 (2) 可行性研究前提： 说明开发项目的功能、 性能和基本要求，达到的目标，各种限制条件，可行性研究方法和决定可行性的主要因素。 (3) 对现有系统的分析：说明现有系统的处理流程和数据流程、工作负荷，各项费用支出，所需各类专业技术人员和数量， 所需各种设备， 现有系统存在什么问题。 (4) 所

14、建设系统的技术可行性分析：对所建设系统的简要说明，处理流程和数据流程，与现有系统比较的优越性， 采用所建议系统对用户的影响，对各种设备、现有软件、开发环境和运行环境的影响，对经费支出的影响，对技术可行性的评价。 (5) 所建议系统的经济可行性分析： 说明所建设系统的各种支出，各种效益，收益/投资比，投资回收周期。 (6) 社会因素可行性分析： 说明法律因素对合同责任、 侵犯专利权和侵犯版权等问题的分析，说明用户使用可行性是否满足用户行政管理、工作制度和人员素制裁的要求。 (7) 其他可供选择方案： 逐一说明其他可供选择的方案， 并说明未被推荐的理由。 (8) 结论意见： 说明项目是否能开发，

15、还需什么条件才能开发，对项目目标有何变动等。2.2 项目开发计划 经过可行性研究后，若一个项目是值得开发的， 则接下来应制定项目开发计划。软件项目开发计划是软件工程中的一种管理性文档。主要是对开发的软件项目的费用、时间、进度、 人员组织、硬件设备的配置、软件开发环境和运行环境的配置等进行说明和规划，是项目管理人员对项目进行管理的依据， 据此对项目的费用、进度和资源进行控制和管理。 项目开发计划是一个管理性的文档， 它的主要内容如下： (1) 项目概述： 说明项目的各项主要工作； 说明软件的功能、性能；为完成项目应具备的条件；用户及合同承包者承担的工作、完成期限及其他条件限制；应交付的程序名称，

16、所使用的语言及存储形式； 应交付的文档。 (2) 实施计划：说明任务的划分，各项任务的责任人；说明项目开进度，按阶段应完成的任务，用图表说明每项任务的开始时间和完成时间； 说明项目的预算，各阶段的费用支出预算。 (3) 人员组织及分工： 说明开发该项目所需人员的类型、 组成结构和数量等。 (4) 交付期限： 说明项目最后完工交付的日期。2.3 软件需求分析 2.3.1 需求分析的特点 在进行可行性研究和项目开发计划以后，如果确认开发一个新的软件系统是必要的而且是可能的，那么就可进入需求分析阶段。 需求分析是指开发人员要准确理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需

17、求定义， 再由需求定义转换到相庆的形式功能规约(需求规格说明)的过程。 需求分析虽处于软件开发过程的开始阶段，但它对于整个软件开发过程以及软件产品质量是至关重要的。在计算机发展的早期，所求解问题的规模国，需求分析被忽视。 随着软件系统复杂性的提高及规模的扩大，需求分析在软件开发中所处的地位愈加突出，从而也愈加困难，它的难点主要体现在以下几个方面： (1) 问题的复杂性。 这是由用户需求所涉及的因素繁多引起的，如运行环境和系统功能等。 (2) 交流障碍。需求分析涉及人员较多， 如软件系统用户、 问题领域专家、需求工程师和项目管理员等，这些人具备不同的背景知识，处于不同的角度， 扮演不同角色，造成

18、了相互之间交注的困难。 (3) 不完备性和不一致性：由于各种原因， 用户对问题的陈述往往是不完备的，其各方面的需求还可能存在着矛盾，需求分析要消除其矛盾，形成完备及一致的定义。 (4) 需求易变性。用户需求的变动是一个极为普便的问题， 即使是部分变动，也往往会影响到需求分析的全部，导致不一致性和不完备性。 为了克服上述困难，人们主要围绕着需求分析的方法及自动化工具(如CASE技术)等方面进行研究。 2.3.2 需求分析的原则 近几年来已提出许多软件需求分析与说明的方法(如结构化分析方法和面向对象分析方法)，每一种分析方法都有独特的观点和表示法， 但都适用下面的基本原则： (1) 必须能够表达和

19、理解问题的数据域和功能域。数据域包括数据流(即数据通过一个系统时的变化方式) 数据内容和数据结构， 而功能域反映上述三方面的控制信息。 (2) 可以把一个复杂问题按功能进行分解并可逐层细化。 通常软件要处理的问题如果太大太复杂就很难理解，若划分成几部分， 并确定各部分间的接口，就可完成整体功能。在需求分析过程中，软件领域中的数据、功能和行为都可划分。 (3) 建模。模型可以帮助分析人员更好地理解软件系统的信息、功能和行为，这些模型也是软件设计的基础。 结构化分析方法(见节)和面向对象分析方法都遵循以上原则。 2.3.3 需求分析的任务 需求分析的基本任务是要准确地定义新系统的目标，为了满足用户

20、需要，回答系统必须“做什么”的问题。在可行性研究和项目开发计划阶段对这个问题的回答是概括的、粗略的。 1. 问题识别 双方确定对问题综合需求。 这些需求包括： (1) 功能需求。所开发的软件必须具备什么样的功能， 这是最重要的。 (2) 性能需求。待开发的软件的技术性能指标， 如存储容量、 运行时间等限制。 (3) 环境需求。软件运行时所需要的软、硬件(如机型、 外投、 操作系统和数据库管理系统等)的要求。 (4) 用户界面需求。人机交互方式、输入输出数据格式等。另外还有可靠性、安全性、保密性、可移植性和可维护性等方面的需求，这些需求一般通过双方交流、调查研究来获取， 并害到共同的理解。 2.

21、 分析与综合， 导出软件的逻辑模型 分析人员对获取的需求，进行一致性的分析检查，在分析、 综合中逐步细分软件功能，划分成各个子功能。这里也包括对数据域进行分解，并分配到各个子功能上，以确定系统的构成及主要成分，并用图文结合的形式，建立起新系统的逻辑模型。 3. 编写文档 编写文档的步骤如下： (1) 编写“需求说明书”，把双方共同的理解与分析结果用规范的方式描述出来，作为今后各项工作的基础。 (2) 编写初步用户使用手册，着重反映被开发软件的用户功能界面和用户使用的具体要求，用户手册能强制分析人员从用户使用的观点考虑软件。 (3) 编写确认测试计划， 作为今后确认和验收的依据。 (4) 修改完

22、善项目开发计划。 在需求分析阶段对开发的系统有了更进一步的了解，所以能更准确地估计开发成本、进度及资源要求，因此对原计划要进行适当修正。 2.3.4 需求分析的方法 需求分析方法有功能分解方法、结构化分析方法、信息建模方法和面向对象分析方法等。 1. 功能分解方法 功能分解方法是将一个系统看成是由若干功能构成的一个集合，每个功能又可划分成若干个加工(即子功能)，一个加工又进一步分解成若干加工步骤(即子加工)。这样，功能分解方法有功能、子功能和功能接口三个组成要素。它的关键策略是利用已有的经验，对一个新系统预先设定加工和加工步骤， 着眼点放在这个新系统需要进行什么样的加工上。 功能分解方法本质上

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

24、系统，它由数据流图和数据词典构成。这种方法简单实用，适于数据处理领域问题。 该方法沿现实世界中的数据流进行分析，把数据流映射到分析结果中。但现实世界中的有些要求不是以数据流为主干的， 就难于用此方法。如果分析是在现有系统的基础上进行的， 应先除去原来物理上的特性，增加新的逻辑要求，再追加新的物理上的考虑。这时，分析面对的并不是问题空间本身，而是过去对问题空间的某一映射，在这种焦点已经错位的前提下， 来进行分析显然是十分困难的。 该方法的一个难点是确定数据流之间的变换，而且数据词典的规模也是一个问题，它会引起所谓的“数据词典爆炸”， 同时对数据结构的强调很少。 3. 信息建模方法 信息建模方法是

25、从数据的角度来对现实世界建立模型的， 它对问题空间的认识是很有帮助的。 该方法的基本工具是ER图，其基本要素由实体、属性和联系构成。 该方法的基本策略是从现实世界中找出实体，然后再用属性来描述这些实体。 信息模型和语义数据模型是紧密相关的，有时被看作是数据库模型。在信息模型中，实体E是一个对象或一组对象。实体把信息收集在其中，关系R是实体之间的联系或交互作用。 有时在实体和关系之外，再加上属性。实体和关系形成一个网络，描述系统的信息状况，给出系统的信息模型。 信息建模和面向对象分析很接近， 但仍有很大有效期距。 在ER图中，数据不封闭，每个实体和它的属性的处理需求不是组合在同一实体中的，没有继

26、承性和消息传递机制来支持模型。 但ER图是面向对象分析的基础。 4. 面向对象的分析 面向对象的分析是把ER图中的概念与面向对象程序设计语言中的主要概念结合在一起而形成的一种分析方法。 在该方法中采用了实体、关系和属性等信息模型分析中的概念，同时采用了封闭、类结构和继承性等面向对象程序设计语言中的概念。 2.3.5 需求分析的文档 需求说明书是需求分析阶段最重要的技术文档之一。 它提供了用户与开发人员对开发软件的共同理解，其作用相当于用户与开发单位之间的技术合同，是今后各阶段设计工作的基础， 也是本阶段评审和测试阶段确认与验收的依据。需求说明书的主要内容如下： (1) 前言：说明项目的目的、范

27、围，所用的术语的定义； 用到的缩略语和缩写词；参考资料。 (2) 项目概述： 产品的描述； 产品的功能； 用户的特点； 一般的约束等。 (3) 具体需求： 说明每个功能的输入、 处理和输出； 外部接口需求，包括用户接口、软件接口、硬件接口和通信接口； 性能需求；设计约束；其他需求，包括数据库、操作等。2.4 IDEF 方 法 IDEF方法是美国空军1981年在针对集成化计算机辅助制造(Integrated Computer Aided Manufacturing, 简称ICAM)工程项目中用于进行复杂系统分析和设计的方法，是在结构化分析与设计技术的基础上提出来的。IDEF是ICAM Defin

28、ition的缩写。 IDEF方法分为三部分： (1) IDEF0： 用来描述系统的功能活动及其联系， 建立系统的功能模型。 (2) IDEF1: 用来描述系统的信息及其联系，建立系统的信息模型。 美国空军项目组对IDEF1进行了扩充与完善，于1985年正式推出了IDEF1x。 (3) IDEF2： 用来进行系统模拟， 建立系统的动态模型。 这里主介绍系统的IDEF0功能模型， 反映系统“做什么”的功能。 2.4.1 IDEF0的图形表示 IDEF0方法采用简单的图形符号和简洁的文字说明， 描述系统在不同层次上的功能。在该方法中，将系统功能称为活动， 将表示系统功能的图形称为活动图形。在活动图形

29、中，用方框和箭头表示系统的各种活动及相互间的关系。图 2.2 表示了一个活动图形，其中“调整工资”即为活动， 用主动的动词短语为描述。 在系统分解的某一层次，可能有多个活动， 为阅读方便， 给每个活动编号， 并注在方框的右下角。 图 2.2 一个活动图形 连在方框上的箭头有 4 种类型：输入、输出、控制和机制。 其中，输入指完成某项活动所需的数据，用连在方框左边的箭头表示；输出指执行活动时产生的数据，用连在方框右边的箭头表示；控制活动指所受到的约束条件，用连在方框上边的箭头表示；机械指活动是由谁来完成的，它可以是人、组织、 设备及其他系统等，用连在方框下边的箭头表示。 有时，输入与控制的意义不

30、易区别，一般情况下输入是活动要“消化掉”或“变换成输出”的数据，而控制只是说明由输入变换到输出的条件， 当无法区分进可将输入看作控制。 一个活动可无输入， 但必须至少有一个控制。 2.4.2 建立功能模型的基本方法 1. 建模基本方法 建立功能模型的基本方法有 4 步： 1) 确定建模的范围、 观点及目的 在开始为系统建立模型时，首先要确定建模的立足点， 包括范围、观点及目的。范围指所讲座的对象是什么，它的边界和外部接口是什么； 观点指从什么角度去考虑所研究的问题， 目的指确定所研究问题的意图及理由。 2) 建立系统的内外关系图A-0图 IDEF0方法建立的功能模型是一组有层次关系的图形， 用字母A开头的编号来标志图形在层次中的位置。 先建立系统的内外关系图，该图用来抽象地描述所研究的问题及其边界或数据接口。图中只有一个活动，活动名概括地描述系统的内容，用进入和离开的箭头表示系统与环境的数据接口， 确定了系统边界。 3) 建立顶层图A0图 把A-0图分解为36个主要部分便得到A0图，它清楚地表达了A-0图在同样信息范围内的细节，从结构上反映了模型的观点， 是系统功