第3章软件需求分析_项目实践精解：IT项目的面向对象分析设计、开发及管理-QQ阅读男生都市网

上QQ阅读APP看本书，新人免费读10天

设备和账号都新为新人

第3章软件需求分析

3.1 软件需求分析概述

需求分析是整个项目开发流程的第一个环节，它是在用户和软件开发组之间建立对用户的共同理解，由软件开发组进行分析、精化并详细描述后，按文档规范编写出《软件需求规格说明书》（Software Requirement Specification，SRS）的过程。

软件需求分析特别重要。在软件工程的历史中，很长时间里人们一直认为需求分析是整个软件工程中的一个简单步骤，但在过去十多年中，越来越多的人认识到它是整个过程中最关键的一个过程。只有通过软件需求分析，才能把软件功能和性能的总体情况描述为具体的软件需求规格说明，从而奠定软件开发的基础。许多大型应用系统的失败，最后均归结为需求分析的失败：要么获取需求的方法不当，使得需求分析不到位或不彻底，导致开发者反复多次地进行需求分析，致使设计、编码、测试无法顺利进行；要么客户配合不好，导致客户对需求不确认，或客户需求不断变化，同样致使设计、编码、测试无法顺利进行。

需求分析是一项重要的工作，也是一项极为困难的工作。该阶段的工作具有以下几个特点。

（1）用户与开发人员很难进行交流

在软件生命周期中，其他4个阶段都是面向软件技术方面的，只有本阶段是面向用户的。需求分析是指对用户的业务活动进行分析，以便明确在用户的业务环境中软件系统应该“做什么”。但是在开始时，开发人员和用户双方都不能准确地提出系统要“做什么”，因为软件开发人员不是用户问题领域的专家，不熟悉用户的业务活动和业务环境，又不可能在短期内搞清楚；而用户不熟悉计算机应用的有关问题。由于双方互相不了解对方的工作，又缺乏共同语言，所以在交流时存在着隔阂。

（2）用户的需求是动态变化的

对于一个大型而复杂的软件系统，用户很难精确、完整地提出它的功能和性能要求。一开始只能提出一个大概、模糊的功能，只有经过长时间的反复认识才逐步明确。有时进入到设计、编程阶段才能明确，更有甚者，到开发后期还在提新的要求。这无疑给软件开发带来了许多困难。

（3）系统变更的代价呈非线性增长

需求分析是软件开发的基础。假定在该阶段发现一个错误，解决它需要用一个小时的时间，到设计、编程、测试和维护阶段解决，则要花费2.5、5、25甚至100倍的时间。

3.2 软件需求分析过程

3.2.1 什么是软件需求

从根本上讲，软件需求就是为了解决现实世界中的特定问题，软件必须展现的属性。

软件需求包括两部分：功能性需求和非功能性需求。虽然功能性需求是对软件系统的一项基本需求，但却并不是唯一的需求。除功能性需求外，软件质量属性的特性，称为系统的非功能性需求。这些特性包括：系统的易用性、执行速度、可靠性，处理异常情况的能力与方式等。在决定系统的成功或失败的因素中，满足非功能性需求往往比满足功能性需求更为重要。软件需求的组成关系见图3-1。

图3-1 软件需求的组成关系

软件需求的属性包括可验证性、优先级、唯一性和定量化。

（1）可验证性

可验证性是软件需求的基本属性。软件需求必须是可验证的，否则软件的评审和测试就没有相应的依据。

（2）优先级

软件需求具有优先级，应该能够在资源有限（资金、人员、技术）的情况下进行取舍。

（3）唯一性

软件需求应唯一地标识出来，以便在软件配置管理和整个软件生命周期中进行管理。

（4）定量化

软件需求应尽可能地表述清楚，没有二义性，并进行适当的量化，应避免含糊、无法测试、无法验证的需求出现。软件质量的可靠性和用户界面的友好性等非功能性需求的量化尤为重要。例如，系统应支持2000个并发用户，系统回应时间应低于10秒，这就是需求的量化。

3.2.2 需求过程中的角色

需求过程涉及各种角色的人员。需求分析人员应协调软件开发人员和各领域内的专家共同完成需求过程。软件的涉众（牵涉到的角色）随项目的不同而不同，但至少包括用户（操作人员）和客户。典型的需求过程中的角色如表3-1所示。

表3-1 需求过程中的角色

对于涉众的各种需求通常很难完全满足，系统分析师应根据预算、技术等条件进行取舍。

3.2.3 需求过程的迭代

软件需求分析是一个不断认识和逐步细化的过程。该过程将软件计划阶段所确定的软件范围（工作范围）逐步细化到可详细定义的程度，并分析出各种不同的软件元素，然后为这些元素找到可行的解决办法。需求过程要适应客户和项目的环境，并作为配置项纳入配置管理。

当前的软件业面临着巨大的竞争压力，要求软件企业有更低的构建成本和更短的开发周期。有些项目受环境的影响很大，有些项目是对原有项目的升级，有些项目客户要求在指定的架构下完成。在项目初期，客户不能完全确定需要什么，对计算机的能力和限制不甚了解，所以需求过程很难是一步到位的过程。随着项目的深入，需求将随时间的推移而发生变化。

因此，需求过程是一个迭代的过程，每次迭代都提供更高质量和更详细的软件需求。这种迭代会给项目带来一定的风险，上一次迭代的设计实现可能会因为需求不足而被推翻。但是，系统分析师应根据项目计划，在给定的资源条件下得到尽可能高质量的需求。

在很多情况下，对需求的理解会随着设计和实现的进行而不断深入，这也会导致在软件生命周期的后期重新修订软件需求。原因可能来自于错误的分析、客户环境和业务流程的改变、市场趋势的变化等。无论什么原因，系统分析师应认识到需求变化的必然性，并采取相应的措施减少需求变更对软件系统的影响。需求的变更必须经过仔细的需求评审、需求跟踪和比较分析后才能实施。

3.2.4 需求来源

理解问题域的第一步是提取需求，即确定需求的来源，识别软件的涉众，确立开发团队与客户间的关系。提取需求时，要求用户与开发人员之间保持良好的沟通。

软件的需求来源很多，我们要尽可能多地识别显式的来源和潜在的来源，并评估这些来源对系统的影响。典型的来源包括以下5种。

（1）系统目的

系统目的是指软件的整体目的或高层的目标。这是进行软件开发的动机，但它们通常表达得比较模糊。系统分析师需要仔细地评估这些目标的价值和成本，对系统的整体目标进行可行性研究。

（2）行业知识

系统分析师需要获取业务领域内的相关知识。因为涉众对于通用的行业知识会一概而过，一些行业惯例需要系统分析师根据环境进行推断。当需求发生矛盾时，系统分析师可以利用行业知识对各种需求进行权衡。

（3）软件涉众

应充分考虑不同软件涉众的需求，如果只强调某一角色的需求，忽略其他角色的需求，往往将导致软件系统的失败。系统分析师应从不同涉众的角度去识别、表述他们的需求。用户的文化差异、客户的组织结构，常常会是系统难以正常实施的原因。

（4）运行环境

软件的运行环境包括地域限制、实时性要求和网络性能等。系统的可行性和软件架构都依赖于这些环境需求。

（5）组织环境

软件作为一个组织的业务流程支持工具，受到组织结构、企业文化和内部政策的影响。软件的需求也与组织结构、企业文化和内部政策有关。

3.2.5 需求获取方法

常用的需求获取方法有：

（1）实地参加

通过亲自参加业务工作来了解业务活动的情况。这种方法可以比较准确地理解用户的需求，但比较耗费时间。

（2）开调查会

通过与用户座谈来了解业务活动情况及用户需求。座谈时，参加者之间可以相互启发。

（3）请专人介绍

（4）面谈

对于某些调查中的问题，可以找专人询问。

（5）设计调查表请用户填写

如果调查表设计得合理，这种方法是很有效的，也很易于被用户接受。

（6）查阅记录

查阅与原系统有关的数据记录，包括原始单据、账簿、报表等。

通过调查了解获取了用户需求后，还需要进一步分析和表达用户的需求。

3.2.6 软件需求表达

如何有效地表达软件需求？我们这里建议使用用例建模技术。用例建模技术是十多年来最重要的需求分析技术，在保障全球各类软件的成功开发中发挥了极其重要的作用。实践证明，用例技术是迄今为止最为深刻、准确和有效的系统功能需求描述方法。功能需求是指系统输入到输出的映射，以及它们的不同组合，任何功能必然要通过外部环境与系统之间的交互才能完成，因此，我们可以在内容和形式上把用例和系统的功能需求等同起来。

用例建模技术不同于结构化功能分解的特点有：

（1）显式地表达用户的任务目标层次，突出系统行为与用户利益间的关系。

（2）通过描述执行实例情节（交互行为序列、正常/非正常事件流），能够完整地反映软件系统用以支持特定功能的行为。

（3）以契约（前/后置条件等）的形式突出了用户和系统之间常常被忽略的背后关系。

（4）部署约束等非功能需求与系统行为直接绑定，能够更准确地表达此类需求。

基于用例的需求表达体系如图3-2所示。

图3-2 基于用例的需求表达体系

1.用例图

（1）用例图概述

用例建模技术离不开用例图。在UML中，用例图又叫做用况图，有时又称为Use Case图。它用于定义系统的行为、展示角色（系统的外部实体，即参入者）与用例（系统执行的服务）之间的相互作用。用例图是需求和系统行为设计的高层模型，它以图形化的方式描述外部实体对系统功能的感知。用例图从用户的角度来组织需求，每个用例描述一个特定的任务，如表3-2所示。

表3-2 用例图概述

用例模型可以在不同层次上建立，具有不同的粒度。

（2）用例层次

我们把用例划分为3个目标层次：概要层、用户目标层和子功能层，并通过引入巧妙的Why/How技术帮助分析者找到合适的目标层次，从而可以有效地把握用例的粒度（真正的用例最终应落实到用户目标层）。

值得注意的是，我们在实践中应该尤其关注用户目标层用例。引入概要层用例的主要目的是为了包含一个或多个用户目标层用例，为系统提供全局功能视图；提出子功能层用例，则是为了表达用户目标层用例的具体实现步骤。

（3）用例范围

根据范围的不同，用例可分为业务用例和系统用例两种。

① 业务用例

● 在业务中执行的一系列动作，这些动作为业务的个体主角产生具有可见价值的结果。

● 实质是业务流程。

● 可以分为核心业务用例，支持业务用例和管理业务用例。

● 主要包括业务角色、业务活动、业务实体、业务规则。

② 系统用例

● 是系统执行的一系列动作，这些动作将生产特定主角可观测的结果值。

● 主要包括系统角色和系统的一系列交互过程。

当前的讨论边界（the System under Discussion，SuD）一般比较容易确定，那么如何从用例的范围上判断一个用例是系统用例还是业务用例呢？如果某个SuD或者用例的范围包含了人及由人组成的团队、部门、组织的活动，那么针对这个SuD写出的用例必然是业务用例；如果该SuD仅仅是一些软件、硬件、机电设备或由它们组成的系统，并不涉及人的业务活动，那么根据这个SuD写出来的用例就是系统用例。

（4）用例关系

① 角色和角色之间

继承关系：表示子类角色将继承父类角色在用例中所能担任的角色。

② 角色和用例之间

使用关系：表示角色将使用用例提供的服务。

③ 用例和用例之间

包含关系：通常是指一个大的用例包含了几个小的用例，几个小的用例组成一个大的用例。

扩展关系：基于扩展点之上的两个独立用例，扩展用例为基本用例的实例增添新的行为，其实质是扩展事件流的延伸，两个用例本身都是独立的。

继承关系：父用例可以通过特化形成一个或多个子用例，这些子用例代表了父用例比较特殊的形式。子用例继承父用例的所有结构、行为和关系。

表现用例关系的实例如图3-3所示。

图3-3 用例关系实例

2.用例描述

用例模型除了绘制用例图外，还要对用例进行描述，也就是详细展开每个用例的内容。用例描述可以是文字性的，也可以用活动图进行说明。文字性的用例描述模板如表3-3 所示。以“借书登记”为例，其具体的用例描述如表3-4所示。

表3-3 用例描述模板

表3-4 借书登记用例描述

3.用例优先级

（1）为什么要设定需求的优先级

每一个具有有限资源的软件项目必须理解所要求的特性、使用实例和功能需求的相对优先级。设定优先级意味着权衡每个需求的业务利益和它的费用，以及它所牵涉到的结构基础和对产品的未来评价。项目经理必须权衡合理的项目范围和进度安排，以及预算、人力资源及质量目标的约束。

设定优先级有助于项目经理解决冲突、安排阶段性交付，并且做出必要的取舍。

● 当客户的期望很高、开发时间短并且资源有限时，必须尽早确定所交付的产品应具备的最重要的功能。

● 建立每个功能的相对重要性有助于规划软件的构造，以最少的费用提供产品的最大功能。

● 当采用渐增式开发方式时，设定优先级就特别重要。因为在开发过程中，交付进度安排很紧，并且日期不可改变，必须排除或推迟一些不重要的功能。

（2）系统分析员的态度和做法

● 在需求分析阶段，分析人员应该明确地提出需求的优先级和处理策略，并在《软件需求规格说明书》中明确说明。

● 应当在项目的早期阶段设定优先级，这有助于逐步做出相互协调的决策，而不是在最后阶段匆忙决定。

● 评价优先级时，应该看到不同需求之间的内在联系，以及它们与项目业务需求的一致性。

● 在判断出需求的低优先级之前，如果开发人员已经实现了将近一半的特性和功能，那么这将是一种浪费，这个责任应该由分析人员承担。

（3）设定优先级的方法

与在客观世界中人们对事务的分类习惯与方法一致，系统需求的优先级设定分成3类。例如：高、中、低；基本的、条件的、可选的；3、2、1……

具体描述如表3-5所示。

表3-5 系统需求的优先级分类

3.2.7 需求评审

1.需求评审概述

需求评审是一项精益求精的技术，它主要由非软件开发人员来进行。通过评审发现二义性的或不确定的需求，还有那些实际上是设计规格说明的所谓的“需求”，这些“需求”是不能作为设计基础和依据的。需求评审也为风险承担者们提供了在特定问题上达成共识的方法。

需求评审可以分为非正式评审和正式评审。

● 非正式评审：可以根据个人爱好的方式进行评审，包括在任何场合的交流、征求意见。它是非系统化的、不彻底的，或者在实施过程中具有不一致性。非正式评审不需要记录备案，没有人对提出的意见负责。

● 正式评审：正式技术评审的最好类型叫做审查，它遵循预先定义好的一系列步骤、过程及规定的方法和要求进行，评审内容需要记录在案，正式评审小组的成员对评审的质量负责。

2.需求评审过程

（1）确定参与者

① 审查参与者必须代表3个方面的观点：

● 需求提出人员和产品代表者的观点。

● 需求分析、开发、管理人员的观点。

● 软件设计、开发、测试、管理人员的观点。

② 审查组中的审查人员应限制在7个人左右或者更少。

③ 审查的工作基础是《软件需求规格说明书》。

（2）参与者扮演的角色

① 作者：创建或维护正在被审查的产品。作者在审查中却起着被动的作用，作者经常可以发现其他审查员没有觉察到的错误。

② 协调者：与作者一起为审查制订计划，组织与协调各种活动，并且推进审查会的进行。督促作者对需求文档做出建议性的更改，以保证向执行者明确说明在审查过程中提出的问题和缺陷。

③ 读者：扮演审查员的角色。在审查会进行期间，读者一次审查规格说明中的一块内容，并做出解释，而且允许其他审查员在审查时提出问题。对于一份需求规格说明，审查员每次必须对需求给出注解或一个简短评论。通过用自己的话来陈述，读者可能做出与其他审查员不同的解释，这将有利于发现二义性或可能的错误。

④ 记录员：用标准化的形式记录在审查会中提出的问题和缺陷。

（3）审查阶段流程（见图3-4）

图3-4 审查阶段流程

（4）进入和退出审查的标准

① 文档进入审查的标准：

● 文档符合标准模板。

● 文档已经做过拼写检查和语法检查。

● 作者已经检查了文档在版面上所存在的错误。

● 已经获得了审查员所需要的先前系统的运行资料或确认所需要的参考文档，例如系统需求规格说明。

● 在文档中打印了行序号以方便对特定位置的查阅和标记。

● 所有未解决的问题都被标记为TBD（待确定）。

● 文档中使用到的术语词汇表已全部进行了说明。

② 文档退出审查的标准：

● 已经明确阐述了审查员提出的所有问题。

● 已经正确修改了文档。

● 修订过的文档已经进行了拼写检查和语法检查。

● 所有TBD的问题已经全部解决，或者已经记录下每个待确定问题的解决过程、目标日期和提出问题的人。

● 文档已经录入项目的配置管理系统。

● 已将审查过的资料送到有关归档部门。

（5）需求审查清单

① 《软件需求规格说明书》审查清单：

● 组织和完整性。

● 正确性。

● 质量属性。

● 可跟踪性。

● 特殊的问题。

② 使用实例审查清单：

● Use Case是否是独立的分散任务。

● Use Case的目标或价值度量是否明确。

● Use Case给操作者带来的益处是否明确。

● Use Case是否处于抽象级别上，而不具有详细的情节。

● Use Case中是否不包含设计和实现的细节。

● 是否记录了所有可能的可选过程。

● 是否记录了所有可能的例外条件。

● 是否存在一些普通的动作序列可以分解成独立的Use Case。

● 是否简明书写、无二义性和完整地记录了每个过程的对话。

● Use Case中的每个操作和步骤是否都与所执行的任务相关。

● Use Case中定义的每个过程是否都可行。

● Use Case中定义的每个过程是否都可确认。

3.3 软件需求文档及ERP系统需求规格说明书

接下来我们需要将上面的需求分析过程通过文档记录下来。软件需求文档虽然可以有各种不同的格式，但它的主要内容包括用例描述和界面导航图。关于用例描述，前面已经做了详细讲解，接下来简单介绍一下界面导航图。

● 系统的界面导航关系，体现了系统对外的宏观交互行为，实际上是系统外在行为最表层实现的一种全局视图，因此也可以看做是系统典型协作的总体概貌描述。

● 可以在项目的较早阶段，规划系统的界面导航图，描述用户的操作将如何触发系统从一个界面转向其他界面的导航过程。

● 界面导航图将静态的界面原型连接成一体，在某种意义上是对需求的一种总体刻画和阐释，用户往往可以从界面导航图领会到系统功能的大体结构。

用户界面的设计编入《软件需求规格说明书》中既有好处也有坏处：

● 由于屏幕图像和用户界面构架是系统设计，而不是用户需求，所以对它的关注可能使需求误入歧途，也限制了开发人员的发挥。

● 但是探讨屏幕图像和用户界面有助于精化需求，并使用户对系统有亲和感和现实感，有助于用户需求的表述和交流。

● 一个合理的权衡点是，在《软件需求规格说明书》中加入用户界面组件的概念草图，而在实现时并不一定要精确地遵循这些草图模型。

ERP系统需求规格说明书

1 引言

1.1 编写目的

此需求规格说明书对项目的背景、范围、验收标准和需求等信息进行说明，包括功能性需求和非功能性需求，确保对用户需求的理解一致。

预期的读者有（甲方）需求提供者、项目负责人、相关技术人员等，北京亚思晟商务科技有限公司（乙方）的项目组成员，包括项目经理、客户经理、分析/设计/开发/测试等人员。

1.2 背景

本ERP系统是基于互联网的应用软件，是为东北某城市一大型工业生产企业提供的全面企业管理解决方案。其组成包括采购、销售、生产、质量、人事、考勤、财务、档案、设备、新品、基础数据等模块。此处将与生产相关的模块功能进行详细介绍。

1.3 定义

● 成品入库分为两种：一种为生产中的成品入库，另一种为采购中的成品入库。

● 凡是出库须判断现有库存量，要审核的须审核后才能确认出库。

● 半成品库中，材料名称指的是原材料库中的“材质”，材质+规格可唯一判定该材料。

● 材料进厂指的是：“原材料在外加工后形成的半成品”进厂入库。

● 转序卡中的数量指的是：根据材料而得出投放数量，一批材料可对应多个转序卡。

● 转序卡中的成品入库数量指的是：投放后该产品的实际入库数量。当第一张转序卡的剩余数量为零时，入库的产品数量转入下一张转序卡。

● 转序卡中的报废数量指的是：投放后该产品的实际报废或核销数量。当第一张转序卡的剩余数量为零时，报废或核销的产品数量转入下一张转序卡。

● 每张转序卡中的剩余数量=投放数量-入库数量-报废或核销数量。

● 材料请领是有计划的一个投放。

● 成品库中的零件号与其总承号同义，半成品库中分为零件总承号、零件号。

● 返修品出库与入库要有对应关系，一次出库可能多次入库，总数量有对应关系。

● 废品是有原因的报废，须追究相关责任人；核销是定期有针对性、有正当原因的处理。核销必须有申请与审核，原因如锈蚀、产品件下线等多种。

● 实现盘点：只要单击盘点，所有库房同时冻结，接着所有库房的期末数都冻结，时间点之后的所有单子不参加逻辑运算；然后生成一个所有库房的期末数的盘点单，也就是期末数的汇总报表，然后打印。根据账面的期末数（也就是盘点时的期末数）到各个库房对实物数量进行核对，核对后出盘盈盘亏，查出原因及调整库存数量后，才可以重新解冻，进行后面所有入出单子的逻辑运算。

● 所有的成品不一定都有半成品。

● 一个零件名称可能有多个零件号。

● 盘盈数量加上现有库存修改库存数量。

● 现有库存减去盘亏数量修改库存数量。

1.4 参考资料

ERP系统理论和实践

2 任务概述

2.1 目标

本ERP系统是基于互联网的应用软件，通过此系统可以实现采购、销售、生产、质量、人事、考勤、财务、档案、设备、新品管理等核心业务，实现企业各部门工作流程的优化重组，超越时间、空间和部门分隔的限制，建成一个精简、高效、廉洁、公平的运作模式，以便全方位地实现企业优质、规范、透明、符合国际水准的管理。该软件系统是一项独立的软件，整个项目外包给北京亚思晟商务科技有限公司来开发、维护。

2.2 用户的特点

本软件的最终用户为企业内的日常使用者，操作人员和维护人员有较高的教育水平和技术专长，同时使用的用户数量初步估计为100人左右。

2.3 假定和约束

假定此系统为自包含的，不过分依赖其他外部系统。本项目的开发期限为6个月。

3 需求规定

整体功能用例图（Use Case Diagram），见图1。

图1

4 用例规格

4.1 公共信息管理

用例描述：

（1）角色：系统管理员

（2）前提条件：登录

（3）主事件流

1. 单击进入公共信息管理模块

2. 单击部门维护（S1）

3. 单击员工基本信息（S2）

（4）分支事件流

S1: 部门维护（E1）

1. 添加部门

2. 修改部门

3. 删除部门

4. 返回部门列表页面

S2: 员工基本信息（E2）

1. 添加员工基本信息

2. 修改员工基本信息

3. 删除员工基本信息

4. 返回员工列表页面

（5）异常事件流

E1: 无法添加、修改、删除部门

E2: 无法添加、修改、删除员工

4.1.1 “部门维护”用户界面

进入界面：单击左侧菜单栏中的“公共信息管理”，打开后单击“部门维护”，进入“部门维护”界面，如图2所示。

图2

选中左侧树图中的结点，如“总部”，然后单击“添加部门”按钮，将生成新的编号，在下面各输入框内输入相应信息，如图3所示。

图3

单击“添加”按钮，将在选中的部门下生成新的子部门。操作成功的界面如图4所示。

图4

注意：类别应填2、3等，指的是所在树形结构中的级别，如2为在总部下面。

选中左侧树图中的部门（如“总部”），然后单击“操作”按钮，可在右侧修改或删除此部门的信息，如图5所示。

图5

修改或删除成功后的效果如图6所示。

图6

4.1.2 用户界面

单击左侧的“公共信息管理”，打开菜单后单击“员工基本信息”，进入“员工基本信息”界面，如图7所示。

在“部门”下拉列表框中选中员工所在的部门，在输入框内输入员工姓名，然后单击“保存”按钮，如图8所示。

保存成功后的界面如图9所示。

图7

图8

图9

4.2 基础信息管理

用例描述：

（1）角色：库房管理员

（2）前提条件：登录

（3）主事件流

1. 单击进入基本信息管理模块

2. 单击半成品库（S1）

3. 单击成品库（S2）

4.单击原材料库（S3）

5. 单击辅助材料库（S4）

6. 单击标准价库（S5）

7. 单击工具库（S6）

8. 单击工装备件库（S7）

9. 单击工序基础信息（S8）

10. 单击定额基础信息（S9）

（4）分支事件流

S1: 半成品库（E1）

1. 添加半成品库

2. 修改半成品库

3. 删除半成品库

4. 返回半成品库列表页面

S2: 成品库（E2）

1. 添加成品库

2. 修改成品库

3. 删除成品库

4. 返回成品库列表页面

S3: 原材料库（E3）

1. 添加原材料库

2. 修改原材料库

3. 删除原材料库

4. 返回原材料库列表页面

S4: 辅助材料库（E4）

1. 添加辅助材料库

2. 修改辅助材料库

3. 删除辅助材料库

4. 返回辅助材料库列表信息

S5: 标准件库（E5）

1. 添加标准件库

2. 修改标准件库

3. 删除标准件库

4. 返回标准件库列表信息

S6: 工具库（E6）

1. 添加工具库

2. 修改工具库

3. 删除工具库

4. 返回工具库列表信息

S7: 工装备件库（E7）

1. 添加工装备件库

2. 修改工装备件库

3. 删除工装备件库

4. 返回工装备件库列表信息

S8: 工序基础信息（E8）

1. 添加工序基础信息

2. 修改工序基础信息

3. 删除工序基础信息

4. 返回工序列表页面

S9: 定额基础信息（E9）

1. 添加定额基础信息

2. 修改定额基础信息

3. 删除定额基础信息

4. 返回定额列表页面

（5）异常事件流

E1: 无法添加、修改、删除半成品库

E2: 无法添加、修改、删除成品库

E3: 无法添加、修改、删除原材料库

E4: 无法添加、修改、删除辅助材料库

E5: 无法添加、修改、删除标准件库

E6: 无法添加、修改、删除工具库

E7: 无法添加、修改、删除工装备件库

E8: 无法添加、修改、删除工序基础信息

E9: 无法添加、修改、删除定额基础信息

4.2.1 “半成品库”用户界面

单击左侧的“基础信息管理”菜单，找到“半成品库”，单击后进入“半成品库”维护界面，如图10所示。

单击“添加”按钮，进入添加新半成品的界面，如图11所示。

图10

图11

首先选择公司，根据公司选择零件总承号，然后添加对应的各项基本信息，如图12所示。

图12

说明：公司名称与零件总承号可在基础信息管理的“成品库”中先维护，详见4.2.2。

单击“添加”按钮，正确添加后，则在“提示”处显示“1”，如图13所示。

图13

单击“返回”，返回到“半成品库”主界面。

单击主界面中的“查看”按钮，可查看当前记录的详细信息，同时也可修改当前记录。

单击主界面中的“新增厂家”，打开添加后，公司名称不可改变，新增半成品信息。

单击主界面中的“新增零件”，打开添加后，公司名称与零件总承号不可改变，在此基础上添加新的半成品信息，操作界面同“添加”。

选中主界面中的复选框后，单击“删除”按钮，可直接删除选中的记录。

4.2.2 “成品库”用户界面

单击左侧“基础信息管理”中的“成品库”，进入成品库管理界面，如图14所示。

图14

选中某个复选框，然后单击“删除”按钮，即可删除对应的记录如图15所示。

图15

删除成功后，界面如图16所示。

图16

单击“添加”按钮，进入添加界面，添加信息，如图17所示。

图17

注意：此处的查询功能，是为查询已有的公司而设的。在公司输入框内输入要查询的公司名称或某一部分，便可在“查询”下拉列表框内查出相应的公司名称，查出后需填写到公司名称处，才可保存。

查询功能如图18所示。

图18

选择时间控件时的界面如图19所示。

添加成功后，“提示”处为“1”，界面如图20所示。

图19

图20

单击主界面中的“查看/修改”，进入“查看/修改”界面，如图21所示。

图21

单击“修改”按钮，可修改当前记录，成功后，“提示”处为“1”，如图22所示。

图22

单击“返回”按钮返回主界面。单击“新增公司”按钮，进入的界面如图23所示。

公司名称不改变，新增产品信息。

图23

单击主界面上的“新增零件”按钮，进入的界面如图24所示。