个人作业——A002-185-2515-郑远曦

一时失言乱红尘 2023-01-01 07:56 101阅读 0赞

计算机科学与工程学院实验报告（首页）  
课程名称 软件需求分析与建模 班级 18软件工程5班  
实验名称 Excel查找结合项目主题说明 教导教师 董瑞生  
姓名 郑远曦 学号 1814080902515 日期 2020．12.20

目录  
1.作业查词说明 1  
1.1 software reuse(软件复用). 3  
1.2 aggregate class(聚合类) 4  
1.3 decision table(判定表) 4  
1.4 functional requirement(功能性需求) 6  
1.5 Requirements baseline(需求基线) 7  
1.6 state-transition diagram(状态转换图) 8  
1.7 behavioral model aspect(模型的行为侧重面) 10  
1.8 binary association(二元关联) 10  
1.9 association end(关联端点) 11  
1.10 collanoration diagram(协作图) 11  
1.11 deployment diagram(部署图) 12  
1.12 focus of control(控制焦点) 15  
1.13 generalization(泛化) 15  
1.14 implementation view(开发视图) 16  
1.15 incremental development(增量开发) 17  
1.16 interaction diagram(交互图) 18  
1.17 logical view(逻辑视图) 19  
1.18 model element(模型元素) 20  
1.19 multiple classification(复合分类) 20  
1.20 multiple inheritance(多继承) 21  
1.21 n-ary association(N-Ary关联) 22  
1.22 Logical Cohesion(逻辑内聚) 22  
1.23 Temporal Cohesion(时序内聚) 23  
1.24 Functional Cohesion（功能内聚） 24  
1.25 Informational Cohesion(信息性内聚) 25  
1.26 Common Coupling(公共耦合) 26  
1.27 Data encapsulation(封装) 26  
1.28 Corrective Maintenance(改正性维护) 28  
1.29 Avoidance strategies(规避策略) 29  
1.30 business reengineering(业务流程重组) 30  
1.31 class hierarchy(多重继承) 31  
1.32 concurrent substate(子状态) 32  
1.33 containment hierarchy(容器分层结构) 33  
1.34 defect density(缺陷密度) 35  
1.35 design subsystem(设计子系统) 36  
1.36 distributed processing(分布式处理) 37  
1.37 generalizable element(可泛化元素) 38  
1.38 interface inheritance(接口继承) 39  
1.39 Pseudo-classes(伪类) 41  
1.40 Process Asset Library(过程资产库) 42  
1.41 Software Requirements Specifications(软件需求规格说明) 43  
1.42 tagged value(标记值) 44  
1.43 use-case diagram(用例图) 44  
1.44 actor-generalization(主角泛化关系) 45  
1.45 architectural pattern(架构模式) 45  
1.46 Agile Processes(敏捷开发) 47  
1.47 rapid prototype(快速原型模型) 48  
1.48 Content Coupling(内容耦合) 48  
1.49 External Coupling(外部耦合) 50  
1.50 Control Coupling (控制耦合) 50  
2.读书笔记 55  
《需求工程—软件建模与分析》读后感 55  
3.对项目的发展建议 56  
对绿小萝项目的发展建议 56

1.  作业查词说明  
    1.1 software reuse(软件复用)  
    名词解释：software reuse as “the systematic use of existing software assets to construct new or modified assets.  
    详细解释：软件复用(softwarereuse) : 提高软件生产力和质量的一种技术，将已有软件的各种有关知识用于建立新的软件，以缩减软件开发和维护的花费。早期的软件复用主要是代码级复用，被复用的知识专指程序，后来扩大到包括领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面。软件复用是一种计算机软件工程方法和理论。60年代的“软件危机”使程序设计人员明白难于维护的软件成本是极其高昂的，当软件的规模不断扩大时，这种软件的综合成本可以说是没有人能负担的，并且即使投入了高昂的资金也难以得到可靠的产品，而软件重用的思想是解决这一问题的根本方法。  
    1.2 aggregate class(聚合类)  
    名词解释：A class that represents the "whole"in an aggregation (whole-part)relationship.  
    详细解释：在软件开发中也存在类似于电视机一样的类，他们可以存储了多个成员对象（元素），这些类通常称为聚合类（Aggregate Class），对应的对象称为聚合对象。聚合类使得用户可以直接访问成员，并且具有特殊的初始化语法形式。当一个类满足如下条件时，我们说它是聚合的：  
    ·所有成员都是public的。  
    ·没有定义任何构造函数。  
    ·没有类内初始值。  
    ·没有基类，也没有virtual函数。  
    1.3 decision table  
    名词解释：A tabular,systematic representation of a complex decision that depends on multiple criteria  
    详细解释：判定表（Decision Table）是分析和表达多逻辑条件下执行不同操作的情况下的工具。在程序设计发展的初期，判定表就已被当作编写程序的辅助工具了。由于它可以把复杂的逻辑关系和多种条件组合的情况表达得既具体又明确。  
    判定表通常由四个部分组成。  
    条件桩（Condition Stub）：列出了问题得所有条件。通常认为列出得条件的次序无关紧要。  
    动作桩（Action Stub）：列出了问题规定可能采取的操作。这些操作的排列顺序没有约束。  
    条件项（Condition Entry）：列出针对它左列条件的取值。在所有可能情况下的真假值。  
    动作项（Action Entry）：列出在条件项的各种取值情况下应该采取的动作。  
    规则：任何一个条件组合的特定取值及其相应要执行的操作。在判定表中贯穿条件项和动作项的一列就是一条规则。显然，判定表中列出多少组条件取值，也就有多少条规则，既条件项和动作项有多少列。  
    判定表的建立步骤（根据软件规格说明）：

1.  确定规则的个数。假如有n个条件，每个条件有两个取值（0，1），故有n2种规则。
2.  列出所有的条件桩和动作桩。
3.  填入条件项。
4.  填入动作项。等到初始判定表。
5.  简化。合并相似规则（相同动作）。  
    Beizer 指出了适合使用判定表设计测试用例的条件：
6.  规格说明以判定表形式给出，或很容易转换成判定表。
7.  条件的排列顺序不会也不影响执行哪些操作。
8.  规则的排列顺序不会也不影响执行哪些操作。
9.  每当某一规则的条件已经满足，并确定要执行的操作后，不必检验别的规则。
10. 如果某一规则得到满足要执行多个操作，这些操作的执行顺序无关紧要。  
    1.4 functional requirement(功能性需求)  
    名词解释：A requirement concerning a result of behavior that shall be provided by a function of a system(or of a component or service)  
    详细解释：功能需求 （functional requirement规定开发人员必须在产品中实现的软件功能，用户利用这些功能来完成任务，满足业务需求。功能需求有时也被称作行为需求 （behavīoral requirement），因为习惯上总是用“应该”对其进行描述：“系统应该发送电子邮件来通知用户已接受其预定”。功能需求描述是开发人员需要实现什 么。注意：用户需求不总是被转变成功能需求。产品特性，所谓特性（feature），是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标 得以满足。对商业软件而言，特性则是一组能被客户识别，并帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用 户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。  
    1.5 Requirements baseline(需求基线)  
    名词解释：A baseline for a set of requirements  
    详细解释：需求基线就是把固定的需求都划一根“线”,说明这些需求已经确定下来，添加新的需求或修改原有的需求都必须通过需求变更流程来操作建立需求基线的目的：防止需求的变化给程序架构造成重大影响。  
    需求基线定义：已经通过正式评审和批准的规格说明或产品，可作为进一步开发的基础，而且只有通过正式的变更控制过程才能修改它。  
    需求基线要以一种持续、衡定和易于项目涉众访问的方式存在。需求基线通常以文档的方式纳入配置管理中。需求基线的内容：标识符：为后续的项目工作提供一个共同的交流参照；当前版本号：保证项目的各项工作都建立在最新的一致需求基础之上；源头：在需求进一步深入理解或者改变需求时，可以回溯到需求的源头；理由：提供需求产生的背景知识；优先级：后续的项目工作可以参照优先级进行安排和调度；状态：交流和具体需求相关的项目工作情况；成本、工作量、风险和可变性：为需求的设计和实现提供参考信息，驱动设计和实现工作。其他需求创建的日期和需求相关的项目工作人员需求涉及的子系统需求涉及的产品版本号需求的验收和验证标准需求基线的维护：要合理地控制对需求的更改要维持需求多个版本情况下的正确使用需求基线的内容是项目的共享资产的工作基础，它应该实现统一的管理。配置管理包括：标识配置项版本控制变更控制访问审计状态报告。  
    1.6 state-transition diagram(状态转换图)  
    名词解释：A diagrammatic representation of a state machine  
    详细解释：状态转换的要素  
    状态：  
    tcp定义的11个状态  
    事件：  
    触发TCP状态迁移。事件能够是：本地应用层调用。收到TCP消息(incoming segment)；超时事件(timeout)  
    动作:  
    主要指针对远程Peer产生的动作，如发送确认等。  
    转换中的角色  
    本地应用层 Local App：产生事件。  
    本地tcp实现层 local TCP stack:处理事件。完毕状态转换；在远程tcp上产生事件。  
    远程tcp实现层 remote TCP stack(or peer):和本地TCP功能一致。  
    TCP连接建立（三次握手）的表格表示：  
    socket创建后的默认状态是CLOSED，从这个初始状态開始，socket经历一系列状态变迁(state transition)。

1.7 behavioral model aspect(模型的行为侧重面)  
名词解释：A model aspect that emphasizes the behavior of the instances in a system, including their methods, collaborations, and state histories.  
详细解释：强调系统中实例行为的模型侧重面，包括其方法、协作和状态历史记录。  
1.8 binary association(二元关联)  
名词解释：An association between two classes. A special case of an nary association.  
详细解释：两个对象实例之间的链接（link)，本身可以拥有自己的性质或属性。例如，一个交易(Trade)是买方(Buyer)和卖方(Supplier)的关联。交易可以有产品名称、数量、价格等。这些属性属于交易自身，而非买方或卖方。因而，链接的属性是关联中两个对象的共同胜质，不属于任何一方。这一点跟多重性完全一样。  
1.9 association end(关联端点)  
名词解释：The endpoint of an association, which connects the association to a classifier.  
详细解释：一个关联端标识实体类型上的一个端部的关联，并且可以在关联的端部存在实体类型的实例的数目。关联结束定义为关联的一部分；一个关联必须恰好有两个关联结束。导航属性允许从一个关联端导航到另一关联端。  
关联结束定义包含以下信息：  
关联中涉及的实体类型之一。（需要）  
一个关联端多重指示实体类型的实例，可以是在关联的一端的数量。关联结束多重性的值可以为一（1），零或一（0…1）或许多（\*）。关联结束的名称。（可选的）有关在关联端执行的操作的信息，例如在删除时级联。（可选的）  
1.10 collanoration diagram(协作图)  
名词解释：A diagram that shows interactions organized around the structure of a model, using either classifiers and associations or instances and links. Unlike a sequence diagram, a collaboration diagram shows the relationships among the instances. Sequence diagrams and collaboration diagrams express similar information, but show it in different ways. See: sequence diagram.  
详细解释：协作图是动态图的另一种表现形式，它强调参加交互的各对象的组织。协作图的组成元素  
对象（Object）  
矩形中的内容代表对象  
链（Link）  
消息 （Message）  
举例——客户取车  
取车的动作从客户开始，她向预定申请模块发送出示清单的消息，然后由公司员工向预定申请模块发送核对的消息，预定申请在收到消息核对的信息后，回复公司员工申请存在，然后再回复客户允许客户取车。公司员工收到消息后填写工作记录和登记汽车状态。

协作图和时序图的关系  
二者在语义上等价  
二者可以互相转化  
二者侧重点不同  
时序图侧重时间顺序  
协作图侧重对象之间的关系，时间顺序从序列号获得  
协作图与时序图的互换  
学生学位评审的流程如下：教务人员将需评审的学生的学号输入学位初评模块，学位初评模块会查询相应写生的成绩和奖惩记录来作为学位评定的依据。学位初评模块将初评的结果打印，学位初评打印稿被提交给教务人员，控制流结束。  
1.11 deployment diagram(部署图)  
名词解释：A diagram that shows the configuration of run-time processing nodes and the components, processes, and objects that live on them. Components represent run-time manifestations of code units.See: component diagrams  
详细解释：部署图是结构图的一种，它展示了系统的架构。例如：一个软件系统的众多实体（Artifacts）是如何构成部署目标（Node，节点）的。  
实体（Artifact）表示在现实世界中具体的元素。实体通常是开发过程的结果，例如：可执行文件、库、存档、数据库schema、配置文件等等。  
部署目标（Deployment target）：通常用节点（Node）来表示，代表一个硬件设备或某些软件运行环境。节点可以通过communication paths构成任意复杂度的、网络连接的系统。  
注意：在UML1.x部署图规范中，组件可以直接部署到节点中。但是在UML2.x规范中，实体可以部署到节点，实体也可以实现组件。组件则可以通过实体间接部署到节点。  
部署图可以用于描述规范级别的架构，也可以描述实例级别的架构。这与类图和对象图有点类似。  
规范级别：展示从实体到节点的部署情况。不涉及具体的实体实例或节点实例。  
实例级别：展示实体实例到具体的节点实例的部署情况。它可以用于展示不同部署之间的差异。例如，开发和生产环境的部署可以通过具体的名字或ID（这里指的是具体的构建、部署服务器、或设备）加以区分。  
1.12 focus of control(控制焦点)  
名词解释：A symbol on a sequence diagram that shows the period of time during which an object is performing an action, either directly or through a subordinate procedure.  
详细解释：控制焦点是顺序图中表示时间段的符号，在这个时间段内对象将执行相应的操作。用小矩形表示

1.13 generalization(泛化)  
名词解释：A taxonomic relationship between a more general element and a more specific element. The more specific element is fully consistent with the more general element and contains additional information. An instance of the more specific element may be used where the more general element is allowed. See: inheritance.  
详细解释：把一般的类连接到特殊的类，有点像是子父类继承关系  
1.14 implementation view(开发视图)  
名词解释：A definition of how something is constructed or computed. For example, a class is an implementation of a type, a method is an implementation of an op  
详细解释：描述软件在开发环境下的静态组织，从程序实现人员的角度透视系统，也叫做实现视图(implementation view)。开发视图关注程序包，不仅包括要编写的源程序，还包括可以直接使用的第三方SDK和现成框架、类库，以及开发的系统将运行于其上的系统软件或中间件, 在UML中用组件图，包图来表述。开发视图和逻辑视图之间可能存在一定的映射关系：比如逻辑层一般会映射到多个程序包等。软件架构的开发视图应当为开发人员提供切实的指导。任何影响全局的设计决策都应由架构设计来完成，这些决策如果"漏"到了后边，最终到了大规模并行开发阶段才发现，可能造成"程序员碰头儿临时决定"的情况大量出现，软件质量必然将下降甚至导致项目失败。  
1.15 incremental development(增量开发)  
名词解释：Incremental development in software engineering is a process methodology that emphasizes the virtue of taking small steps toward the goal. In contrast to the waterfall model of software development, in which a working system becomes available only in the later phases of the project, incremental development begins with a small, working system that is improved and expanded step by step.  
详细解释：继承技术的优点之一，就是它支持增量开发模式。你可以引入新代码而不会在现有代码中引  
发 Bug。事实上，这种模式可以将新的 Bug 隔离在新的代码之中。通过从现有的、功能性  
的类继承并添加数据成员和成员方法（并重新定义现有方法），就可以使别人可能仍在使用  
中的现有代码既不会被改变也不会新增 Bug。  
类被隔离得如此之干净，实在令人惊奇。你甚至不需要为了复用程序代码而调用方法的源代  
码，充其量只需要导入（import）一个包即可（这对继承和组合都适用）。  
我们要认识到程序开发是一种增量过程，犹如人类的学习一样，这一点很重要。你可以尽你  
所能去分析，但当你开始执行一个项目时，你仍然无法知道所有的答案。如果你将项目视作  
是一种有机的、进化着的生命体而去培养，而不是打算像盖摩天大楼一样快速见效，你就会  
获得更多的成功和更迅速的回馈。  
1.16 interaction diagram(交互图)  
名词解释：A generic term that applies to several types of diagrams that emphasize object interactions. These include: collaboration diagrams, sequence diagrams, and activity diagrams.  
详细解释：交互图（Interaction Diagram）用来描述系统中的对象是如何进行相互作用的。即一组对象是如何进行消息传递的。当交互图建模时，通常既包括对象（每个对象都扮演某一特定的角色），又包括消息（每个消息都代表对象之间的通信活动，并导致一定的动作发生）。交互主要用于描述协作的动态行为方面，包括：顺序图（强调消息的事件顺序） 、 合作图（强调对象之间的交互关系）。  
1.17 logical view(逻辑视图)  
名词解释：The logical view provides a hierarchical view of a project’s structure. With the logical view, users can create and customize the diagrams in their projects with meaningful categorization by adding domain-specific view(s).  
详细解释：主要是整个系统的抽象结构表述，关注系统提供最终用户的功能，不涉及具体的编译即输出和部署，通常在UML中用类图，交互图，时序图来表述，类似与我们采用OOA的对象模型。逻辑视图主要支持系统的功能需求，即系统提供给最终用户的服务。在逻辑视图中，系统分解成一系列的功能抽象，这些抽象主要来自问题领域。这种分解不但可以用来进行功能分析，而且可用作标识在整个系统的各个不同部分的通用机制和设计元素。在OO技术中，通过抽象、封装和继承，可以用对象模型来代表逻辑视图，用类图来描述逻辑视图。逻辑视图中使用的风格为面向对象的风格，在设计中要注意保持一个单一的、内聚的对象模型贯穿整个系统。  
1.18 model element  
名词解释：An element that is an abstraction drawn from the system being modeled. Contrast: view element.  
详细解释：每个视角的模型元素通过可追溯性和合理性链接与先前（或有时是先前）视角的模型元素链接。  
在大多数情况下，这些链接连接具有相同性质的元素，如表23.6所示（并非详尽无遗）。

1.19 multiple classification(复合分类)  
名词解释：A semantic variation of generalization in which an object may belong directly to more than one class. See: dynamic classification.  
详细解释：在计算机科学中，复合类型是一种数据类型，它可以原始类型和其它的复合类型所构成。构成一个复合类型的动作，又称作组合。  
1.20 multiple inheritance(多继承)  
名词解释：A semantic variation of generalization in which a type may have more than one supertype. Contrast: single inheritance.  
详细解释：多继承是指一个子类继承自两个或两个以上的基类

*  语法：  
    　　class 类名（基类名，基类名２, …）:  
    pass
 *  说明：  
    　　一个子类同时继承自多个父类，父类中的方法可以同时被继承下来  
    如果两个父类中有同名的方法，而在子类中又没有覆盖此方法，调用结果难以确定  
    多继承的缺陷：  
    标识符冲突问题  
    要谨慎使用多继承  
    1.21 n-ary association(N-Ary关联)  
    名词解释：An association among three or more classes. Each instance of the association is an n-tuple of values from the respective classes. Contrast: binary association.  
    详细解释：n-Ary Asociation元素用于模拟三个或更多元素之间的复杂关系，通常在类图中。它不是一种常用的设备，但可以在几个元素之间存在依赖关系的情况下发挥良好效果。它通常与Association连接器一起使用，但关系可以包括其他类型的连接器。

1.22 Logical Cohesion(逻辑内聚)  
名词解释：A module may be a function, set of functions or a sub-function, which has its own defined functionality, which can be created, modified or removed independently, without impacting the whole system. Logical cohesion is a concept where all modules that are logically doing the same function are put together.  
详细解释：逻辑内聚指模块内执行个逻辑上相似的功能，通过参数确定该模块完成哪一个功能。指机能相关的程序组合成一模块的程度，或是各机能凝聚的状态或程度。是结构化分析的重要概念之一。量测内聚性的方式很多，有些方法是由分析源代码，得到非量化的结果，有些方法则是检查源代码的文本特征，以得到内聚性的量化分数。内聚性是属于顺序式的量测量，一般会以“高内聚性”或“低内聚性”来表示。一般会希望程序的模块有高内聚性，因为高内聚性一般和许多理想的软件特性有关，包括鲁棒性、可靠度、可复用性及易懂性（understandability）等特性，而低内聚性一般也代表不易维护、不易测试、不易复用以及难以理解。  
1.23 Temporal Cohesion(时序内聚)  
名词解释：In a software program, a module is said to possess temporal cohesion, where the components of that program module get grouped during the time frame when they get processed. In other terms, if a component performs several tasks and the tasks/functions are related by timing, the cohesion is said to be temporal.  
详细解释：时间性内聚性是指将相近时间点运行的程序，放在同一个模块中（例如在捕捉到一个异常后调用一函数，在函数中关闭已打开的文件、产生错误日志、并告知用户）。  
1.24 Functional Cohesion（功能内聚）  
名词解释：Functional cohesion is one of the most important cohesion techniques. In this technique, in a single component, all the essential functional elements are combined together for performing a single computation.  
详细解释：功能聚合是指一个模块内各组成部分全都为执行同一个功能而存在,且只执行同一个功能，由于这种模块只完成一个单独的、能够确切定义的功能,它对确定的输入进行处理后,必然得到确定的输出结果,这是一种“黑箱”模块。这种模块的聚合度最高。判断一个模块是否为功能聚合模块，只要看该模块是只完成一个具体任务,还是完成多种任务或县做一些相互无关的事。 \[1\]  
模块的聚合是指模块内各个组成部分之间的凝聚程度，表示模块功能的专一化程度。聚合度越高，表明模块内各组成部分的凝聚程度越强,模块的独立性越好。在设计模块时,尽量做到系统中的每个模块内部都有很强的聚合度，它的各个组成部分都是彼此密切相关的,是为完成一个单独的功能而组合在一起的。  
1.25 Informational Cohesion(信息性内聚)  
名词解释：Informational Cohesion  
The module performs multiple functions; represented by entry points in the module, deal with a single data structure.  
详细解释：如果模块进行许多操作,每个都有各自的入口点,每个操作的代码相对独立,而且所有操作都在相同的数据结构上完成,则该模块具有“信息性内聚”。  
1.26 Common Coupling(公共耦合)  
名词解释：Common coupling or Global coupling is defined as a form of coupling where different modules share some information through the global data.  
详细解释：公共耦合指通过一个公共数据环境相互作用的那些模块间的耦合.公共数据环境可以是全程变量或数据结构共享的通信,内存的公共覆盖区及任何存储介质上的文件,物理设备等(也有将共享外部设备分类为外部耦合).由于两个模块都要引用同一个公共数据域，因此有较高的耦合度。一旦公共数据有变化，与之有关的模块都应随之而修改,增加了维护的工作量及难度。 \[1\]  
公共耦合是一种不好的耦合关系。若有一个公共数据做了修改,很难判定究竟有多少模块使用了该公共数据，在修改与维护时就有可能出现模块被遗漏的情况。所以,在模块设计时,尽量不要有公共耦合。  
1.27 Data encapsulation(封装)  
名词解释：Data encapsulation refers to sending data where the data is augmented with successive layers of control information before transmission across a network. The reverse of data encapsulation is decapsulation, which refers to the successive layers of data being removed (essentially unwrapped) at the receiving end of a network.  
详细解释：Encapsulation（封装），有时也叫隧道(tunneling)，是将一个协议报文分组插入另一个协议报文分组。本地协议分组“背”着被封装的分组跨过本地协议网传输。  
尽管这增加了额外开销，但它提供了一种将一个网上报文分组通过一个使用不同协议的中间网传送到另一个网上的方法。  
例如，在IP隧道技术中，就可以将NetWare的IPX分组封装到TCP/IP分组中，再象图E-6那样通过TCP/IP网传递。另一个例子是将AppleTalk分组封装到DECnet分组中，通过DECnet开放系统互连(OSI)网发送。在接收端，报文分组被解封并被送到目的地。  
公共数据网提供者，如AT&T用封装的方法在带有同步光纤网(SONET)接口的ATM(异步传输模式)信元交换设备上传送数据分组。在多兆位数据交换服务SMDS中，分组结构在信元交换结构的顶层定义，用户数据分组被封装在SMDS分组中，然后放入信元中，以利用信元交换的高速性。  
封装也提供了一种使用光纤分布式数据接口(FDDI)作为局域网或校园网的主干网的方法。FDDI信封置于以太网帧外面，整个包通过FDDI主干网传送。当它到达目的网的桥接器时，就被解包并送到目的地。封装通常在大多数以太网到FDDI网桥接器中执行。这种方法假设以太网上的节点决不与直接连到FDDI局域网上的节点通信(桥接器除外)。封装使得帧在它们被接收桥接器解封之前不可用。在将以太网分组送到直接与FDDI局域网相连的工作站上时需进行翻译。  
1.28 Corrective Maintenance(改正性维护)  
名词解释：Corrective maintenance (also called breakdown maintenance) are maintenance tasks that are performed in order to rectify and repair faulty systems and equipment. The purpose of corrective maintenance is to restore broken down systems.  
详细解释：改正性维护是指为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的错误，应当进行的诊断和改正错误的过程。改正性维护是在软件运行中发生异常或故障时进行的维护工作。在软件交付使用后，由于开发时测试的不彻底、不完全，必然会有一部分隐藏的错误被带到运行阶段来。这些隐藏下来的错误在某些特定的使用环境下会暴露出来。为了识别和纠正软件错误、改正软件性能上的缺陷、排除实施中的误使用，应进行的诊断和改正错误的过程，是改正性维护。例如，改正性维护可以是改正原来程序中开关使用的错误；解决开发时未能测试各种可能情况带来的问题；解决原来程序中遗漏处理文件中最后一个记录的问题等。  
1.29 Avoidance strategies  
名词解释：Avoidance coping—also known as avoidant coping, avoidance behaviors, and escape coping—is a maladaptive form of coping in which a person changes their behavior to avoid thinking about, feeling, or doing difficult things.  
详细解释：风险规避是改变项目计划来消除特定风险事件得威胁。通常情况下我们可以采用多种方法来规避风险。  
（1）对于软件项目开发过程中存在得技术风险，我们可以采用成熟得技术，团队成员熟悉得技术或迭代式得开发过程等方法来规避风险。  
（2）对于项目管理风险我们可以采用成熟得项目管理办法和策略来规避不成熟得项目管理带来得风险。  
（3）对于进度风险我们可以采用增量式得开发来规避项目或产品延迟上市得风险  
（4）对于软件项目需求不确定得风险我们可以采用原型法来规避风险。  
1.30 business reengineering(业务流程重组)  
名词解释：Business process reengineering is a crucial element in the agenda of many large as well as small companies in many industries, with manufacturing and banking/ finance being the leading sectors. It allows organizations to view their business processes from a fresh perspective in order to understand how to redesign them to improve the way they work.  
详细解释：业务流程重组（Business Process Reengineering，BPR）最早由美国的Michael Hammer 和James Champy提出，在20世纪90年代达到了全盛的一种管理思想。通常定义为通过对企业战略、增值运营流程以及支撑它们的系统、政策、组织和结构的重组与优化, 达到工作流程和生产力最优化的目的。强调以业务流程为改造对象和中心、以关心客户的需求和满意度为目标、对现有的业务流程进行根本的再思考和彻底的再设计，利用先进的制造技术、信息技术以及现代的管理手段、最大限度地实现技术上的功能集成和管理上的职能集成，以打破传统的职能型组织结构，建立全新的过程型组织结构，从而实现企业经营在成本、质量、服务和速度等方面的突破性的改善。  
业务流程重组最重要的是在组织高管层面有完善的业务流程重组管理计划与实施步骤以及对预期可能出现的障碍与阻力有清醒认识。  
1.31 class hierarchy(多重继承)  
名词解释：As in taxonomy, the classifications of species, a class hierarchy in computer science is a classification of object types, denoting objects as the instantiations of classes inter-relating the various classes by relationships such as “inherits”, “extends”, “is an abstraction of”, “an interface definition”.  
详细解释：多重继承是编程语言中的概念，多重继承指的是一个类可以同时继承多个类，比如A类继承自B类和C类，这就是多重继承。面向对象编程语言中的多重继承指的是一个类可以同时继承多个父类的行为和特征功能。单一继承是指：一个子类只继承一个父类。多重继承指代可以导致某些令人混淆的情况，所以关于它的好处与风险之间孰轻孰重常常受人争论。Java使用了一个折衷的办法：Java允许一个类别继承自多于一个父接口（可以指定某一个类别，它继承了所有父类的类型，并必须拥有所有父类别接口的外部可见方法的具体实现，并允许编译器强制以上要求），但只可以从一个父类别继承实现（方法与数据）。微软的.NET编程语言，例如C\#和Visual Basic .NET和REAL Software的REALbasic也使用了这种类接口的做法。  
1.32 concurrent substate(子状态)  
名词解释：The state is an abstraction given by the values of the attributes that the object has at a particular time period. It is a situation occurring for a finite time period in the lifetime of an object, in which it fulfils certain conditions, performs certain activities, or waits for certain events to occur. In state transition diagrams, a state is represented by rounded rectangles.  
详细解释：子状态(substate)，又称嵌套状态，指出现在另一个状态里面的状态，一系列子状态的集合状态，把一个状态画在另一个状态中表示内部的状态是一个外部状态的子状态。而这个外部状态即为内部状态的父状态。  
子状态以两种形式出现：顺序子状态(sequential substate)和并发子状态(concurrent substate)。  
状态可能有嵌套的子状态，且子状态可以在另一个状态图。子状态又可分为两种：与子状态(and-substate)，或子状态(or-substate)。与子状态指的是一个状态可以有子状态，但是一次只能有一  
个子状态，如图5．14所示。例如，一辆车可以处于运行态，它的运行态可以有两个子状态：前进和后退，它们是或子状态，因为它们不能同时为真。嵌套的子状态可以显示在另一个状态图中，方法是在初始状态图中扩展运行状态。

1.33 containment hierarchy(容器分层结构)  
名词解释：A containment hierarchy is a hierarchical collection of strictly nested sets. Each entry in the hierarchy designates a set such that the previous entry is a strict superset, and the next entry is a strict subset. For example, all rectangles are quadrilaterals, but not all quadrilaterals are rectangles, and all squares are rectangles, but not all rectangles are squares. A hierarchy of this kind is to be contrasted with a more general notion of a partially ordered set.  
详细解释：该任务采用每个系统级用例，然后将其分解为一组子系统级用例。这是在为此目的定义的（新）用例图上完成的。关键关系是用例之间的“包含”关系。你可能还记得从第4章开始，“包含”关系是代表包容性的依赖的刻板印象。也就是说，较大的用例包含了包含的用例。在用例建模中，仅在以下几种情况下使用«include»关系：  
1。为大型系统10创建用例抽象/包含层次结构（系统复杂性管理）  
2。将大型复杂用例分解为更小巧，更易于使用的用例（用例复杂性管理）  
3。提取较小的功能，以供不同用例重用（重用）  
4。将系统级用例的一部分分配给子系统（分配）。  
在这种情况下，我们专注于最后一个-将系统用例分解为一组子系统用例，以便将所有系统用例需求分配给子系统。  
例如，如果我们在图7.12中查看飞机的部分用例集，则会看到«include»的使用将三个用例抽象层次联系起来。在下一个图（图7.13）中，我们采用其中的一个，并使用“ include”关系分解“控制态度”用例，以将子系统级用例分配给飞机架构。

1.34 defect density(缺陷密度)  
名词解释：Defect Density is the number of defects confirmed in software/module during a specific period of operation or development divided by the size of the software/module. It enables one to decide if a piece of software is ready to be released.  
详细解释：基本的缺陷测量是以每千行代码的缺陷数(Defects/KLOC)来测量的。称为缺陷密度(Dd)，其测量单位是defects／KLOC。缺陷密度=缺陷数量/代码行或功能点的数量。  
可按照以下步骤来计算一个程序的缺陷密度：  
1.累计开发过程中每个阶段发现的缺陷总数(D)。  
2.统计程序中新开发的和修改的代码行数(N)。  
3.计算每千行的缺陷数Dd=1000*D/N。例如，一个29.6万行的源程序总共有145个缺陷，则缺陷密度是： Dd＝1000*145/296000=0.49 defects／KLOC。在缺陷密度度量中存在的两个主要困难是：  
1.缺陷权值如何计算：是否将严重程度较轻的缺陷和较重的缺陷同等对待。  
2.代码行怎么统计：代码行的数量可能会因编程人员的技术水平和所使用的语言不同而不同。  
3.对于黑盒测试人员，可能不太容易获取到代码行数。  
1.35 design subsystem(设计子系统)  
名词解释：A model element which has the semantics of a package (it can contain other model elements) and a class (it has behavior). The behavior of the subsystem is provided by classes or other subsystems it contains. A subsystem realizes one or more interfaces, which define the behavior it can perform.  
详细解释：这个活动详细描述了一个给定的ECU系统描述(以前是从已交付的系统摘要中创建的)以及附加的ECU和网络。设计子系统活动: 在ECU系统描述的基础上，定义了一个子系统的描述。不同机构之间的合作: 另外，系统的软件构件结构提取，由主组织交付，由接收组织转化为不同的结构(ECU系统描述)。在这种情况下，主要组织的系统提取可以被视为一个需求，而接收组织的子系统可以被视为一个解决方案，它必须满足交付的需求。因此，这里可以再次定义一个映射活动，它将新引入的解决方案子系统映射到主要组织提供的需求子系统。设计子系统活动期间的转换变化: 在这个转换过程中，分层的swc结构可以改变，一些swc可以被其他swc替换，一些可以保留在结果视图中。  
1.36 distributed processing(分布式处理)  
名词解释：Distributed processing is a setup in which multiple individual central processing units (CPU) work on the same programs, functions or systems to provide more capability for a computer or other device.  
详细解释：分布式处理（distributed processing）和并行处理（Parallel processing）是为了提高并行处理速度采用的两种不同的体系架构。  
并行处理是利用多个功能部件或多个处理机同时工作来提高系统性能或可靠性的计算机系统，这种系统至少包含指令级或指令级以上的并行。  
分布式处理则是将不同地点的，或具有不同功能的，或拥有不同数据的多台计算机通过通信网络连接起来，在控制系统的统一管理控制下，协调地完成大规模信息处理任务的计算机系统。  
并行处理系统的研究与发展涉及计算理论，算法，体系结构，软硬件多个方面，但它与分布式处理系统有密切的关系，随着通信技术的发展，两者的界限越来越模糊。广义上说分布式处理也可以认为是一种并行处理形式。而分布式处理系统将不同地点的或具有不同功能的或拥有不同数据的多台计算机用通信网络连接起来，在控制系统的统一管理控制下，协调地完成信息处理任务的计算机系统。一般认为，集中在同一个机柜内或同一个地点的紧密耦合多处理机系统或大规模并行处理系统是并行处理系统，而用局域网或广域网连接的计算机系统是分布式处理系统。松散耦合并行计算机中的并行操作系统有时也称为分布式处理系统。  
1.37 generalizable element(可泛化元素)  
名词解释：A generalization is a binary taxonomic (i.e. related to classification) directed relationship between a more general classifier (superclass) and a more specific classifier (subclass).  
详细解释：可以参与泛化关系的模型元素。  
见泛化(generalization)、继承(inheritance)语义可泛化元素可以有父和子。被类元成带有元素的变量可以带有该元素后代的实例。  
可泛化元素包括类、用例、其他类元、关联、状态和合作，它们继承其祖先的特征。每种可泛化元素的哪个部分是继承来的，要看元素的种类。例如类继承属性、方法、操作、关联中的地位和约束；关联继承参与类（本身可被特化）和关联端的特性；用例继承属性、操作、与参与者的关联、与其他用例的扩展和包含关系、行为序列。状态继承转换。见泛化(generalization)、关联泛化(association generalization)、用例泛化(use case generalization)。结构可泛化元素的属性声明它可以在泛化关系中的何处出现。  
1.38 interface inheritance(接口继承)  
名词解释：Interface inheritance is nothing but the implementation of interfaces. A class may implement any number of interfaces.  
详细解释：接口是一种高度的抽象，里面会规定一些将要实现的行为或者只作为一种标记，如java中的Serializable接口，它比抽象类更加抽象。然后说说一说对继承的理解，继承就是泛化。在由接口组成的继承层级中，从上往下看，是由抽象到具体的过程。通过继承我们可以保留父接口中定义的行为，同时对其可以做扩展。整个继承层级，其实是类似树结构的，树的层级越深，行为就更越复杂，能做的事情就更多。上一层是对下一层共性的抽象，下层是对上层不同维度的演进。以java的集合框架为例，如下图：

1.39 Pseudo-classes(伪类)  
名词解释：A CSS pseudo-class is a keyword added to a selector that specifies a special state of the selected element(s). For example, :hover can be used to change a button’s color when the user’s pointer hovers over it.  
详细解释：伪类对元素进行分类是基于特征(characteristics)而不是它们的名字、属性或者内容；原则上特征是不可以从文档树上推断得到的。CSS伪类是用来添加一些选择器的特殊效果。解释：在感觉上伪类可以是动态的，当用户和文档进行交互的时候一个元素可以获取或者失去一个伪类。例外的是":first-child"能通过文档树推断出来，":lang"在一些情况下也在从文档树中推断出来。由此可以看出，它的功能和class有些类似，但它是基于文档之外的抽象，所以叫伪类。  
1.40 Process Asset Library(过程资产库)  
名词解释：Process Asset Library (PAL) is a repository, available at the central location in the organization. PAL contains important artefacts required for the Process Improvement in the organization.  
详细解释：所谓过程资产库，是软件组织在 I过程中产生的有价值实体的集合，这些资产横跨各项目过程，形成软件组织持续过程改善的源泉。组织过程资产框组织过程资产指一个学习型组织在项目操作过程中所积累的无形资产。组织过程资产的累积程度是衡量一个项目组织管理体系成熟度的重要指标，项目组织在实践中形成自己独特的过程资产，构成组织的核心竞争力。项目组织在项目管理过程中指定的各种规章制度、指导方针、规范标准、操作程序、工作流程、行为准则和工具方法等。项目组织在项目操作过程中所获得的经验和教训，其中既包括已经形成文字的档案，也包括留在团队成员脑子中没有形成文字的思想。  
1.41 Software Requirements Specifications(软件需求规格说明)  
名词解释：软件需求说明书是指在研究用户要求的基础上，完成可行性分析和投资效益分析以后，由软件工程师或分析员编写的说明书。它详细定义了信息流和界面，功能需求，设计要求和限制，测试准则和质量保证要求。它的作用是作为用户和软件开发人员达成的技术协议书，作为着手进行设计工作的基础和依据，系统开发完成以后，为产品的验收提供了依据。  
详细解释：软件需求说明书，又称为软件规格说明书，是分析员在需求分析阶段需要完成的文档，是软件需求分析的最终结果。它的作用主要是：作为软件人员与用户之间事实上的技术合同说明；作为软件人员下一步进行设计和编码的基础；作为测试和验收的依据。SRS必须用统一格式的文档进行描述，为了使需求分析描述具有统一的风格，可以采用已有的且能满足项目需要的模板，也可以根据项目特点和软件开发小组的特点对标准进行适当的改动，形成自己的模板。软件需求说明主要包括引言、任务概述、需求规定、运行环境规定和附录等内容。  
1.42 tagged value(标记值)  
名词解释：OMG Unified Modeling Language (UML) introduces stereotype and tagged values, which provide designers with ideal solutions to these situations.  
详细解释：标记值是可以分配给UML元素和连接器的其他属性。 UML定义了元素和连接器的名称和描述之类的属性， Enterprise Architect添加了许多其他属性，例如status，phase和author，但是Tagged Values提供了一种定义自己的属性（标签）及其值的方法。例如，需求建模者可能想要记录一组需求的所有者。 UML没有指定此属性，但是可以轻松地将其添加为标签。可以创建一个名为Requirement Owner的标签，然后可以为每个Requirement元素分配一个所有者值。该信息也可以在文档中找到。  
1.43 use-case diagram(用例图)  
名词解释：A UML use case diagram is the primary form of system/software requirements for a new software program underdeveloped. Use cases specify the expected behavior (what), and not the exact method of making it happen (how).  
详细解释：用例图主要用来描述角色以及角色与用例之间的连接关系。说明的是谁要使用系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示这些元素之间的各种关系，如泛化、关联和依赖。它展示了一个外部用户能够观察到的系统功能模型图。用例图中包含6个元素，分别是执行者（Actor），用例（Use Case），关联关系（Association），包含关系(Include)，扩展关系(Extend)以及泛化关系(Generalization)。  
1.44 actor-generalization(主角泛化关系)  
名词解释：Generalization of an actor means that one actor can inherit the role of the other actor. The descendant inherits all the use cases of the ancestor.  
详细解释：从一个主角类（后代）到另一个主角类（祖先）的主角泛化关系，表示后代将继承祖先在用例中所能担任的角色。  
1.45 architectural pattern(架构模式)  
名词解释：Architectural patterns are a method of arranging blocks of functionality to address a need.  
详细解释：架构模式是一个系统的高层次策略，涉及到大尺度的组件以及整体性质和力学。架构模式的好坏可以影响到总体布局和框架性结构。一个架构模式描述软件系统里的基本的结构组织或纲要。架构模式提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。有些作者把这种架构模式叫做系统模式\[STELTING02\]。架构模式常常划分成如下的几种：  
　　一）、 From Mud to Structure型。帮助架构师将系统合理划分，避免形成一个对象的海洋（A sea of objects）。包括Layers（分层）模式、Blackboard（黑板）模式、Pipes/Filters（管道/过滤器）模式等。  
　　二）、分散系统（Distributed Systems）型。为分散式系统提供完整的架构设计，包括像Broker（中介）模式等。  
　　三）、人机互动（Interactive Systems）型，支持包含有人机互动介面的系统的架构设计，例子包括MVC（Model-View-Controller）模式、PAC（Presentation-Abstraction-Control）模式等。  
　　四）、Adaptable Systems型，支持应用系统适应技术的变化、软件功能需求的变化。如Reflection（反射）模式、Microkernel（微核）模式等。  
1.46 Agile Processes(敏捷开发)  
名词解释：Agile Processes is utilized in software development and is a particular approach to Project Management. Incremental, iterative work, sequence commonly known as sprints are used by this method to assist teams in responding to the unpredictability of constructing software.  
详细解释：敏捷开发以用户的需求进化为核心，采用迭代、循序渐进的方法进行软件开发。在敏捷开发中，软件项目在构建初期被切分成多个子项目，各个子项目的成果都经过测试，具备可视、可集成和可运行使用的特征。换言之，就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态. 敏捷建模（AM）定义了一系列的核心原则和辅助原则，它们为软件开发项目中的建模实践奠定了基石。其中一些原则是从XP中借鉴而来，在Extreme Programming Explained中有它们的详细描述。而XP中的一些原则又是源于众所周知的软件工程学。复用的思想随处可见！基本上，本文中对这些原则的阐述主要侧重于它们是如何影响着建模工作；这样，对于这些借鉴于XP的原则，我们可以从另一个角度来看待。  
1.47 rapid prototype(快速原型模型)  
名词解释：Rapid prototyping is the fast fabrication of a physical part, model or assembly using 3D computer aided design (CAD). The creation of the part, model or assembly is usually completed using additive manufacturing, or more commonly known as 3D printing.  
详细解释：原型是指模拟某种产品的原始模型，在其他产业中经常使用。软件开发中的原型是软件的一个早期可运行的版本，它反映了最终系统的重要特性。  
快速原型模型又称原型模型，它是增量模型的另一种形式；它是在开发真实系统之前，构造一个原型，在该原型的基础上，逐渐完成整个系统的开发工作。快速原型模型的第一步是建造一个快速原型，实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。通过逐步调整原型使其满足客户的要求，开发人员可以确定客户的真正需求是什么；第二步则在第一步的基础上开发客户满意的软件产品。  
1.48 Content Coupling(内容耦合)  
名词解释：Content coupling, or pathological coupling, occurs when one module modifies or relies on the internal workings of another module. Changing the inner working will lead to the need of changing the dependent module. An example would be a search method that adds an object which is not found to the internal structure of the data structure used to hold information.  
详细解释：内容耦合是指如果一个模块与另一个模块的内部属性有关，不经调用直接使用另一个模块的程序代码或内部数据，那么这两个模块之间就存在内容耦合。这种耦合表明一个模块与另一个模块的内部数据或程序代码有关，当一个模块的程序代码被修改或内部数据出错,必然引起另一个模块出错。而对后一模块的出错是很难查出原因的，这样给模块的修改、维护带来极大困难。内容耦合的耦合度最大，为“病态耦合”,在设计时,应避免这种耦合。  
当一个模块直接修改或操作另一个模块的数据，或者直接转入另一个模块时，就发生了内容耦合。此时，被修改的模块完全依赖于修改它的模块。如果发生下列情形，两个模块之间就发生了内容耦合  
(1) 一个模块直接访问另一个模块的内部数据；  
(2) 一个模块不通过正常入口转到另一模块内部；  
(3) 两个模块有一部分程序代码重叠（只可能出现在汇编语言中）；  
(4) 一个模块有多个入口。  
1.49 External Coupling(外部耦合)  
名词解释：External coupling occurs when one or more modules share a format, interface or communication protocol, that is imposed upon them. This usually happens when modules are in direct communication with infrastructure layers, e.g., OS functions.  
详细解释：外部耦合是一种简单变量耦合。一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。  
1.50 Control Coupling (控制耦合)  
名词解释：Control coupling occurs when one module controls the flow of another by passing control information, e.g., a control flag, a comparison function passed to a sort algorithm.  
详细解释：控制耦合（control coupling）指一个模块调用另一个模块时，传递的是控制变量（如开关、标志等），被调模块通过该控制变量的值有选择地执行块内某一功能。这种耦合对系统的影响较大，它影响接收控制流模块的内部运行。这种模块严格说不是“黑箱”模块，不利于模块的修改与维护。虽然控制联结的耦合度高于数据耦合，但这种联结有时是必要的。特别对某些反映状态标志的控制信息传递是必须的。控制信息不同于数据信息，是控制处理过程的一些参数。

1.  读书笔记  
    《需求工程—软件建模与分析》读后感  
    这学期学了专业课书籍《需求工程——软件建模与分析》，并在学习之余仔细阅读了正本书的内容。使我对我的专业有了更深的理解，对专业的就业方面有了一定的感悟，对未来工作有了初步认识及相关指导。从事软件工程这一专业，编写代码并不是整个工程的重中之重。软件工程，顾名思义，之所以能被称之为工程，是因为它的的严谨，以及各个环节环环相扣，缺一不可。  
    《需求工程——软件建模与分析》这本书的第二部分的主要讲解了需求获取中的各种活动以及活动中常用的方法与技术，例如背景資料的收集、前景与范围的限定、需求获取源头的确定、重要需求获取方法的应用等。包含了一些必要的分析活动以及分析的方法与技术，前期需求阶段的分析活动、方法及技术，定义前景与范围时涉及的分析活动、方法及技术;涉众分析时涉及的活动、方法及技术;需求获取展开时的场景/用例方法。使我建立了对需求获取活动的整体性、基础性理解。求获取的基本背景、活动框架以及一些细节事项。讲解了确定项目前景和分析，复委情况下的目标分析，NFR和业务过程分析，系统边界的定义和前景与范围文档的端写。讲解了获取来源的确定，顺带展开的主题是对涉众关系的理解和分析。虽然在篇幅和复杂度上附带主题有喧宾夺主之嫌,但本章的主旨是为了讲清需求获取源头的选择和确定。讲解了在明确项目前景和范围之后,以用例/场景模型的组织作用为核心逐步展开用户需求获取的过程。本章的重点是对用例/场景模型的理解和应用。第8章以面谈方法为核心,讲解了面谈、调查问卷、群体面谈、头脑风暴等多种传统的需求获取方法。这些方法的共同点是通过“面对面”(调查问卷除外)及“问-答”(头脑风暴除外)形式完成需求获取。语言上的直接交流关注点，问题准备、语言交流技巧、基本方法准则等事项是重点。  
    通过阅读《需求工程——软件建模与分析》这本书的前及章节，使我更深的认识了软件工程这一专业的复杂，严谨，等特性。让我在学习软件工程这条大路上越走越远。  
    读软件需求分析首先明确了软件需求包含的三个不同层次，业务需求即组织机构或客户的需求目标，用户需求即用户使用产品必须要完成的任务，功能需求即开发人员需要实现的软件功能。从需求的定义上我们可以知道需求关注的是究竟想开发什么与设计细节实现细节项目规划信息或者测试信息无关，不重视需求过程会给项目带来极大风险，所以在需求过程中我们要注意避免以下几种情况，无足够用户参与，用户需求不断扩展，用户需求不明确或者说模棱两可，不必要的特性即为软件画蛇添足，过于精简的规格说明，忽略了用户分类，不准确的计划，而高质量的需求过程要求产品开发过程中的通力合作同时充分了解其市场，因此要想完成一份优秀的需求就必须具备完整性（功能完整），正确性（准确陈述其功能），可行性，必要性（每项需求都硬把客户真正需要的和最终系统），划分优先级，无二义性（只能有一个明确统一的解释），可验证性等特性。同时需求规格说明也需具备完整性，一致性，可修改性，可跟踪性（即每项软件需求与它的根源和设计元素，源代码，测试用例之间建立起链接链）。  
    那么什么是需求工程？需求工程是所有需求处理活动的综合，它收集信息、分析问题、整合挂点、记录需求并验证其正确性，最终反应软件被应用后与其环境互动形成的期望效应。需求工程是为了在软件开发前需要软件工程师们去了解并去设计出一套解决方案。因为软件工程师并不是了解所有领域。所以更加需要更用户沟通。需求工程十分重要。虽然人们很早就认识到这一点，但是在时间、人力、物力、财力的投入上却并没有那么重要。事后必然会导致需求分析水平低，软件开发质量低，用户抱怨多的问题出现。  
    为了解决这样的问题需求分析师们必须具备以下技能以方便、明确、成功的做出需求分析：  
    1.需要专业技能，懂得需求工程的相关知识、理解需求工程的相关理论、熟悉需求工程的各项活动、掌握需求工程的各种办法与技术是必须得；  
    2.是要有分析技能，必须可以从大量信息中提取、分析、整合出有用的信息处理，了解用户需求中的冲突与遗漏，分析可行性；  
    3.需要交流技能，这是必须的，要掌握交谈和提问的技巧，否则很难跟不懂软件的客户出现隔阂，隔行如隔山，大家不能各说各的吧；  
    4.观察技能、建模技能、写作技能、创新技能、协调技能等。需求工程师应该具有敏锐的洞察力，可以通过观察用户的工作环境和工作过程，发现通过谈话及其他方法所无法发现的重要信息。同时也应该掌握从传统流程图到结构化的分析模型，直至当今的统一建模语言等多种分析工具。因为需要跟客户、管理人员、开发人员等交涉信息，所以需要写好书面的需求规格说明书。写作技能是必须的。需求工程师需要通过写作清晰的表达出复杂的概念。
2.  对绿小萝项目的发展建议  
    新装修的房间可能含有超标甲醛，住在甲醛超标的房子里容易使人身体长满红包，严重时会患上白血病，甲醛对人体危害极大！而为了清除甲醛、治理甲醛，人们绞尽脑汁费尽心力，但大多都是徒劳，网上流传的一些除醛方法根本没用，而有部分人却不知道。比如说用菠萝皮、柚子皮除甲醛，其实完全无效；或者用绿植来除甲醛，其效果也是微乎其微……而其他的五花八门的除甲醛方式或者甲醛检测仪的效果也是不尽人意，没有一定的安全与保证。  
    前景：甲醛的释放周期长达3~15年，为了使消费者快速安全舒适放心地早日住进新家，帮助消费者避开各种不可靠除醛技巧的陷阱，绿小萝系统是一个基于Internet的微信小程序，它可以接受消费者的预约，由施工队接取订单并与消费者进行商讨，然后施工队可以到消费者指定位置进行甲醛检测或者处理工作，在工作完成后再结算费用，消费者事后也可以对工作进行反馈并由施工队进行处理。与传统的到除醛施工队门店预约方式相比，这一系统可以更方便的让消费者进行远程预约，不但节约了消费者的时间，还扩大了消费者对信息获取的范围。  
    因为受众比较广，所以在绿小萝开发设计过程中，应该做到以下几点：  
    1、 界面简洁，操作简单。  
    2、 功能设计简便，方便使用  
    3、 注重用户信息的安全  
    4、 代码容易维护和修改