A001-185-2502-李林

作业A001-185-2502-李林
课程名称 软件需求分析与建模
班级 18软件工程5班
教导教师 董瑞生
李林 1814080902502
日期 2020.10.4

---

目录

---

---

通过阅课本软件需求分析与建模一到三章，我学到了很多。软件需求的获取和分析是软件系统开发中的一项重要任务，正确获取软件需求的能力是软件技术人员所应掌握的基

第一章

软件的模拟特性来源于其知识载体的特性：软件在运行中表现岀来的特性、行为应该和应用 的现实情况保持一致。这样，人们通过观察软件的表现就可以得出相应现实问题的答案，即软件“模拟”了现实。
软件的冗余功能问题从另一个侧面反映了它的模拟特性。在软件开发中，一方面只能完成预期功能的60%-70% [Standish 1995],另一方面移交软件中却存在着大量的冗余功能 (接近50% [Young 2002, Standish 2003]),这些功能用户从来不会使用。
软件可以被分为3种类别：面向专业用户的纯工具型软件、面向普通用户的纯工具型软件和 应用型软件。
专业用户通常以软件为中心开展工作，工具软件是他们的主要手段，因此面向专业用户的纯 工具型软件的首要成功标准是要具有功能的复杂性和使用的高效性。功能的复杂可以让专业用 户在执行任务时具有更大的发挥空间和回旋余地。使用的高效可以帮助专业用户更快、更好地 完成任务。应用型软件的模拟特性使得需求处理具有很突岀的特性。相对于软件开发的其他阶段而言，需求处理阶段涉及更多的非技术性和社会性因素，并且其所受的影响也远远高于其他阶段。 20世纪90年代之前的需求处理往往更专注于技术处理，而对其中的非技术性和社会性因素重 视不足。
需求建模与分析是需求处理中的核心活动，它用一些形式化或半形式化的语言进行知识 的描述。一方面，只有通过建模与分析才能将混乱、模糊的用户需求变成清晰、明确的软件需 求，所以它是获取需求处理活动的必然后继，它建立的分析模型是需求处理中最为重要的成 果；另一方面，建模与分析的理论可以帮助人们系统化地看待问题，它可以根据理论或分析中 出现的各种现象指导其他需求处理活动更好地进行。因此，建模与分析活动在需求处理中具有非常重要的地位，以至于人们理所当然地把需求处理工作的重心部署在建模与分析活动中，放在对建模技术的理解和运用上，甚至在传统的软件开发生命周期中用“需求分析”一词 指代整个需求处理阶段。
但在需求处理阶段除了需求建模与分析活动之外，还有其他的活动也应得到重视，理解需求处理中涉及的非技术性和社会性因素与理解建模分析技术一样必要，否则同样会导致软件的失败，这些因素包括组织机构文化、社会背景、商业目标、利益协商等。
传统的需求分析方法，如结构化分析和面向对象分析，都是从设计领域转入分析领域的。虽然它们在设计阶段取得了很大的成功，但它们并不非常适合于需求阶段的技术处理需要，因此它 们在需求处理中的应用具有一定的先天缺陷。
需求处理是软件工程的起始阶段，设计、实现等后续阶段的正确性都以它的正确性为前提。如果在需求处理过程中有错误未能解决，则其后的所有阶段都会受到影响，因此与需求有关的错误修复代价较高，需求问题对软件成败的影响较大。统计表明，在需求阶段发生的错误如果到了维护阶段才发现，则在维护阶段进行修复的代价可能高达需求阶段修复代价的100~200倍 [Boehm 1981, Boehm 2001 ]，这种递增效应也说明了需求问题的高代价性。需求工程是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需 求并验证其正确性，最终反映软件被应用后与其环境互动形成的期望效应。
从细节来看，可以定义如下：需求工程是软件工程的一个分支，它关注软件系统所应实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束，同时也关注以上因素和准确的软件行为规格说明之间的联系，关注以上因素与其随时间或跨产品族而演化之后的相关因素之间的联系。
需求工程活动包括需求开发和需求管理两个方面。需求开发是因为需求工程的“需求”特 性而存在的，它们是专门用来处理需求的软件技术，包括需求获取、需求分析、需求规格说明和需 求验证4个具体的活动。需求管理是因为需求工程的“工程”特性而存在的，它的目的是在开发活动之后，保证所确定的需求能够在后续的项目活动中有效地发挥作用，保证各种活动的开展都符合需求要求。在软件开发的各项活动中，需求工程的任务是连接现实世界与计算机世界，将现实世界的知识内容转化为计算机世界的工作基础，让软件设计、实现、测试等后续的软件开发活动将精力集 中在计算机世界中来。需求工程师是负责完成需求工程主要任务的专门人员，所以他负责衔接现实世界和计算机世界，简单说就是涉众与开发者之间的桥梁。需求工程师的重要性就体现在他的桥梁作用上。
问题在现实世界与软件系统的互动中得到解决。题域的背景信息又被称为问题域特性(problem domain feature) o与需求相区别的是，问题域是自治的，它有自己的运行规律，而且这些规律不会因解系统的引入而发生改变。需求是一种 对未来的期望，是可以打折、部分满足甚至不予满足的；而问题域特性是既定现实，可以改善但不 能忽视，更不能违背的。例如对于需求“将利润率提高到5%”，可以部分满足，只提升到3%。但 是如果用户的销售市场遍布全国(问题域特性)，就不能仅考虑一个地点的销售工作状况。
软件系统通过影响问题域帮助人们解决问题，所以［Jackson 1995b］称之为解系统(solution system)。在解系统中软件起着主要的作用，它是软件解决方案在通用计算机上的实现。
解系统是问题的解决手段，并不是问题的产生地，所以解系统并不是问题域的一部分。解系统与问题域之间存在可以互相影响的接口，以实现交互活动。
需求工程师要注意区分用户与软件开发人员在关注点上的不同：用户关注于问题域，软件开发人员更关注解系统。需求工程师扮演着桥梁的作用，一方面使用户不需要了解和关注解系统(因为用户大多不懂软件开发的专业知识)，另一方面使软件开发者不需要关注问题域，让软件开发者将精力集中到软件构造工作中。尤其需要注意的是：虽然需求工程师通常是技术人员，来自于解系统领域，但是他们也必须要懂得如何站在用户的立场，与用户进行基于问题域的交流。

第二章

处于问题域之外的解系统之所以能解决问题域中的问题，是因为问题域与解系统之间存在有效的互动，并在互动中互相影响。而问题域与解系统能够形成互动的基础是解系统部分模拟了问题域,[Jackson 1995b]将这种模拟性称为共享现象(share phenomenon) 。
模拟是指其中一方仿制另一方的信息。解系统对问题域的模拟则更加复杂一些, 它们之间的模拟性带有交互性：一方面，解系统会在自身中保持一份与问题域现象一致的信息, 并随着问题域现象的变化而变化；另一方面，问题域会期待在解系统中看到一致的信息，并据此展开自己的行为。
因为解系统解决问题的方法是改变共享知识，影响问题域的运行，进而满足用户的需求。所以需求规格说明主要包括两部分（如图2-5所示）：对共享现象（模型）的描述和对系统对共享现象所施加的操作的描述。这也是软件系统中最为核心的两个部分:数据与功能。
如果拥有描述明确的问题域特性E和定义良好 的系统行为S,就可以很容易地发现将系统应用到问题域后会产生的效果。这种效果如果符合预期的需求X,那么系统就是满足人们需要的系统。所以需求工程的目的就是根据E,构建S,使得E和S的联合作用效果符合需求R：E,SJR。
需求是问题解决的期望，问题是可大可小的，期望自然也是可大可小的。例如，一个超市收银员的问题可以是“工作效率太低（大）”，也可以是“商品销售过程太繁琐（中）”， 还 可以是“销 售时计算总价不方便（小）”。
问题和期望粒度不同的现象被称为需求的不同抽象层次。
业务需求是抽象层次最高的需求，是系统建立的战略岀发点，表现为高层次的目标（objec- tive）,它描述了组织为什么要开发系统。例如超市管理系统可以有如下业务需求BR1~BR4O业务需求通常来自项目的投资人、购买产品的顾客、实际用户的管理者、市场营销部门或产品策划部门。
BR1：在系统使用6个月后，商品积压、缺货和报废的现象减少50%。
BR2：在系统使用3个月后，销售人员工作效率提高50%。
BR3：在系统使用6个月后，店铺运营成本降低15%0
•范围：人力成本和库存成本。
・度量：检查平均每个店铺的员工数量和平均每10000元销售额的库存成本。
BR4：在系统使用6个月后，销售额度提高20%（最好情况：40%；最可能情况：20%；最坏情况：10%。）
业务需求必须是可验证的，其验证标准可以是一个数值指标，如BR1-BR4；也可以是一个直 接的有无、是否等判定，例如，下述BR5、BR6验收时就是有与没有的判定。
BR5：跟踪记录储户的存取款情况。
BR6：跟踪记录VIP顾客信息。
业务需求可验证的数值指标是通过研究问题域的背景资料得出的，例如，若大多数商品从入 库到出库的销售周期是6个月，那么就可以将BR1的第一个条件设定为“系统使用6个月后”；如果详细列举原来导致商品积压、缺货和报废的原因及比率，将软件系统能解决的原因及比率累 加后达到50%,就可以将BR1的后一个验证条件写为“商品积压、缺货和报废的现象减少50%”。再如，如果收银员从新手到熟练使用系统的培训周期为3个月，就可以将BR2的第一个条件写 为“系统使用3个月后”；如果实例研究中收银员使用与不使用系统的工作时间为1 ：2,就可以将BR2的第二个条件写为“销售人员工作效率提高50%”。
为了满足用户的业务需求，需求工程师需要描述系统高层次的解决方案，定义系统应该具备的特性(feature)o高层次的解决方案及系统特性指出了系统建立的方向，参与各方必须就它们 达成一致，以建立一个共同的前景(vision)，保证涉众朝着同一个方向努力。以支持业务需求的 满足为衡量标准，系统特性说明了系统为用户提供的各项功能，它限定了系统的范围(scope),定 义良好的系统特性可以帮助用户和开发者确定系统的边界。
为满足超市管理系统的业务需求BR1-BR4,可以设计特性为SF1 -SF10的高层次解决方案。其中 SF1、SF3、SF7 针对 BR1 与 BR3 ,SF2 针对 BR1 与 BR4, SF4、SF5、SF8、SF9 针对 BR4, SF10 针对 BR2 与 BR3。
SF1：分析店铺商品库存，发现可能的商品积压、缺货和报废现象。
SF2：根据市场变化调整销售的商品。
SF3：制定促销手段，处理积压商品。
SF4：与生产厂家联合进行商品促销。
SF5：制定促销手段进行销售竞争。
SF6：掌握员工变动和授权情况。
SF7：处理商品入库与出库。
SF8：发展会员，提高顾客回头率。
SF9：允许积分兑换商品和赠送吸引会员的礼品，提高会员满意度。
SF10：帮助收银员处理销售与退货任务。
高层次的目标是由组织的决策者提出的，但普通用户才是组织中任务的实际执行者，只有通过一套具体并且合理的业务流程才能真正实现目标。用户需求就是执行实际工作的用户对系统所能完成的具体任务的期望，描述了系统能够帮助用户做些什么。用户需求主要来自系统的使用者——用户。在有些情况下，系统的直接用户不可知，如通用的软件系统或社会服务领域的软件系统等，所以用户需求也可能来自间接的渠道，如销售人员和售后支持人员等。
用户需求是对任务的期望，所以其基本表达方式为“xx用户可以使用系统完成xx任务”。用户任务应该是有目标性、有价值的活动。例如在银行ATM系统中，取款、存款、转账都是合理的用户需求，因为它们各自代表了用户的一个目标，但“向ATM中插入银行卡”就不是一个合理的 用户需求，因为用户不会无目的地“向ATM中插入银行卡”。再如，UR1是一个合理的用户需 求，因为它表达了收银员的一个任务，但是“收银员使用扫描仪扫描商品条码”就不是合理的用 户需求，因为收银员的目的是记录商品，而扫描条码只是手段。
业务需求描述了系统的目标与效益，适合决策者；用户需求描述了具体任务，适合用户；它 们都不适合于软件开发者。适合软件开发者的需求层次是系统级需求，它关注的是软件系统 的行为，尤其是系统与外界的交互行为：在接收到一个外界请求时，软件系统应该给外界提供 响应。所以系统级需求的典型形式是“系统可以XXX”或者"在XX用户提出XX请求时，系统应 该XXX”。
因为系统级需求比用户需求更详细，数量更多，所以为了节省开发时间，在实际开发中有些开发者更愿意使用用户需求而不是系统级需求作为后续开发的基础。这种做法在一定程度上是可行的，但也有风险：用户需求不够准确，给开发人员提供了过大的发挥空间，可能导致开发人员在需求理解上出现偏差，因为开发人员未能从用户需求描述中得到足够信息以准确 地完成设计与实现工作，就只能以自身的经验进行假设，这些假设未必是合理的。
一个软件系统的系统级需求集合定义了相应业务需求及用户需求的解决方案，构成了需求规格说明的主体部分。解系统及其需求规格说明都是不属于现实的，是人们为了解决问题而构建的，所以系统级需求无法直接从现实中得到。相比之下，业务需求直接或间接地来源于决策者，用户需求直接或间接地来源于用户，而系统级需求就只能通过技术加工获得。技术加工过程被称为需求分析，其源对象是用户需求及相关的问题域知识，处理方式是利用分析方法、技术建立需求分析模型，并基于需求分析模型将用户需求及问题域知识转化为系统 级需求。将用户需求转化为系统级需求是一个复杂的活动，详细情况请参见本书的需求分析部分。
在3个不同层次的功能需求中，业务需求具有明显的目的 性和较高的抽象性，比较容易获取和确认。所以需求开发往往从获取业务需求开始。有了业务需求之后，就可以确定系统的最终目标和努力方向，进而指导具体的需求获取活动，发现用户需求。用户需求经过明确和细化的处理，可以转化为系统级需求。
从另一个角度讲，系统开发者理想中的需求是系统级需求，因为开发者可以直接将系统级需求映射为系统行为，进行设计和开发。
但是因为系统级需求是无法直接或间接从现实中获取的，所以开发者只能退而求其次——获取用户需求，并通过分析活动将其转化为系统级需求。
随之而来的另一个问题是，用户需求的获取过程非常复杂，涉及众多参与者和诸多问题，要成功地获取用户需求，首先要协调参与者的立场和问题的范围，而这只能通过对业务需求的处理进行解决一根据业务需求，协调涉众的立场，限定问题的范围，指导用户需求的获取过程。
分类的目的是为了区别对待，否则分类就失去了意义。需求分类是为了将需求划分为需要区别对待的不同类型，每种类型会被文档化到不同的部分，服务于不同的读者、不同的目的。
人们在软件开发中谈论“需求”时，通常是指软件需求，本书中使用“需求”一词时也主要用来指称软件需求。但有时“需求”一词也会被用来指称其他类型的需求。
功能需求是软件系统需求中最常见和最重要的需求，同时也是最为复杂的需求。
通常一个软件系统的绝大部分需求都是功能需求。虽然在类别划分上功能需求只是5种类别之一，但在比例上功能需求有可能占所有需求的90%以上。进行这样不均衡比例的划分，是因为功能需求的处理方式是一致的。
功能需求是一个软件产品得以存在的原因，是软件系统能够解决用户问题和产生价值的基础，也是整个软件开发工作的基础。所有开发者都需要了解功能需求。在复杂的系统中功能需求数量太多，所以需要将它组织为多个独立部分，然后按照分工原则由不同的开发者来处理不同 的部分。
在大规模软件系统中，因为其功能需求比较复杂，所以它是最需要按照3个抽象层次进行展开的需求类别，也就是说功能需求的开发要围绕“目标-任务-交互”(例如BR2t UR1-UR4 , URliSRl~SR2、DRl、Rule3)的路线进行，对“目标”“任务”和“交互”3个概念的关注是功能需 求开发的重中之重。
[IEEE 1990]对性能的定义是：一个系统或其组成部分在限定的约束下，完成其指定功能的 程度，如速度、精确性和内存使用程度等。性能需求定义了系统必须多好和多快地完成专门的功能。
常见的性能需求包括以下几种。
①速度(speed)：系统完成任务的时间，如PR1O
PR1 :所有的用户査询都必须在10 s内完成。
②容量(capacity):系统所能存储的数据量，如PR2。
PR2：系统应该能够存储至少10万条销售记录。
③吞吐量(throughput)；系统在连续的时间内完成的事务数量，如PR3。
PR3：解释器每分钟应该至少解析5 000条没有错误的语句。
④负载(load):系统可以承载的并发工作量，如PR4。
PR4：系统应该允许200个用户同时进行正常的工作。
⑤实时性(time-critical):严格的实时要求，如PR5。
PR5：监测到病人异常后，监控器必须在0.5 s内发岀警报。
性能需求的定义要适合于运行环境。过于宽松的性能要求会带来用户的不满，过于苛刻的 性能要求会给系统的设计造成不必要的负担，所以给出一个合适的量化目标是非常关键的，但同时也是非常困难的。更加常见的方法是在限定性能目标的同时给出一定的灵活性(如PR6)或 者给出多个不同层次的目标要求(如PR7)。
PR6：98%的査询不能超过10 s。
PR7：(最低标准)在200个用户并发时，系统不能崩溃；
(一般标准)在200个用户并发时，系统应该在80%的时间内能正常工作；
(理想标准)在200个用户并发时，系统应该能保持正常的工作状态。
将性能需求划分为独立的类别，文档化为独立的部分，是因为它有其他类别需求都不具备的动态性一理论上说，只有开发完成并实际运行系统，才能确定软件系统的性能。实际工作中，软件体系结构师、系统工程师等人员需要特别关注性能需求，必要时需要专门进行模拟。
在软件系统的开发和使用过程中，人们很自然地关注系统的功能，它是系统能够为用户提供帮助的第一要素。但成功的软件系统除了满足功能需求之外，还需要满足更多的要求，如易于使用和少出错等。
功能需求是用户对软件系统的显式要求，用户在软件系统创建之前就可以清晰地向开发者 表达这种要求。而非功能需求属于隐式要求，用户在软件系统创建之前无法清晰地告诉开发者 他们希望该系统具备什么样的非功能性特征。但是在软件系统投入使用之后，他们却可以快速 判断出软件系统的哪一部分非功能需求不满足他们的条件。例如，在市场买一双鞋子时，对于鞋子功能（休闲、跑步还是踢足球）的要求是显式的，但是对鞋底是否会脱胶、鞋面坚韧度等特性的 要求就是隐式的，虽然不会有明文规定鞋底不能脱胶，但是一旦脱胶就会被认为是鞋子质量不合格。一般认为，具备职业素质的人员能够在用户不提及的情况下认识到用户的隐式要求，否则该人员就是不合格的。
成功的软件系统必须满足显式的及隐含的各种要求。系统为满足显式的及隐含的要求而需要具备的要素称为质量。
为了度量一个系统的质量，人们通常会选用系统的某些质量要素进行量化处理，建立质量特征，这些特征称为质量属性。
需要注意的是质量属性需求包含性能需求，只是性能需求比较特殊，所以被独立为单独的类型。
实际工作中，软件体系结构师会比较关心质量需求，因为妥善解决质量问题是软件体系结构师的主要工作。
质量属性应该和功能需求一样得到足够的重视。真实的现实系统中，在决定系统的成功或失败的因素中，满足非功能属性往往比满足功能需求更为重要°
质量属性对设计的影响很大。在软件设计中对任何指定的功能都会有多种可选的方案，不同的方案选择产生不同的设计结果。这些不同的设计结果都体现了共同的功能特性，但它 们之间却有着很大的区别，差异之处即在于拥有不同的质量因素。设计方案的质量因素往往 包含很多不同的质量属性，而且不同的质量属性之间互有折中(如提高可移植性往往会导致 效率降低)，很难会岀现某一个设计方案的质量属性完全优于其他方案的情况。因此，软件设计必须根据需求的质量属性在多种方案中选择一个最优的方案。如果不存在事先定义 好的质量属性需求，设计方案的选择将完全没有依据，结果就很有可能导致软件不被用户接受。
对于一个已经完成的设计，如果需要修改其功能，则需要对设计进行一定的调整或拓展。但如果需要修改其质量属性要求，在复杂的情况下就可能会需要重新进行设计方案的选择，受到的影响就是整个设计而不再仅仅局限于其某个部分。所以，在设计开始之初就确定质量属性要求非常重要，而且对越复杂的系统越为重要。
虽然用户会在和需求工程师交流的过程中表达一些和质量属性相关的想法，但因为他们并不了解软件系统的开发过程，也就无从判断哪些质量属性会在怎样的程度上给设计带来多大的影响，也无法将他们对软件系统的质量要求细化成一组组可量化的质量属性，所以一般来说，他们并不能明确地提出对产品质量的期望。
在发现质量属性后，要想了解用户的真正想法，需求工程师还需要和用户以及开发人员一起从多个角度进行质量的定义。进行质量属性的定义时，应当将其与相联系的功能需求关联起来。 不能和功能需求建立联系的全局性质量属性应该统一进行处理。
约束是不受解系统影响，却会给解系统带来极大影响的问题域特性。因为不受解系统的影响，所以从解决问题的角度来看约束不会要求解系统为其进行专门的设计。但是如果解系统不满足约束，那就意味着问题域并不能够提供解系统要求的运行环境，解系统将无法在问题域内成功地部署和运行。因此，约束是在总体上限制了开发人员设计和构建系统时的选择范围。
这些约束通常会影响后续的体系结构设计、详细设计、实现、测试等软件开发活动。
每一项需求都必须正确描述所需要的系统功能，要真实反映用户的意图，所以需求的正确性又常被称为真实性（real）。需求的正确性只有提出需求的人才能加以判断，所以需求在传递给开发人员之前，必须请需求的提出者予以确认。
正确性是一个看上去简单,但实践中很难满足的特性。实践一再表明，不真实的需求是最为常见的需求错误之一，必须得到足够的重视。
需求能够正确传递知识的前提是传递者和受众能够形成共同的理解，因此每一项需求都应该有而且只能有一种解释，即需求无歧义。为了让需求可理解，一般倾向于以用户的语言描述需 求，而用户的语言往往含有大量容易导致歧义的因素，因此在保证需求描述的无歧义时要格外注意需求描述中的词汇选择，通常在需求开发中要定义一个可以共同理解的词汇表(glossary),然 后再在其基础上进行需求的描述。
模糊和歧义也是实践中常见的需求错误类型，它多数是被无意写出的，少数情况下也可能被有意写出。

第三章

需求获取是从人、文档或环境中获取需求的过程。获取过程并不是简单地将定义良好的需求从人、文档或环境中直接转移到获取的结果文档上，需求工程师必须要利用各种方法和技术来“发现”需求。
需求开发的过程包含有学习和认知的过程，而学习和认知的过程是递进的，即学习一点，增 加一些认知，然后在新的认知的基础上继续学习。因此需求获取和需求分析是交织在一起的，需求工程师需要获取一些信息，随即进行分析和整理，理解、认知到一定程度后再确定要进一步获 取的内容。
获取的目的是发现用户的问题，并经过需求分析步骤转化为用户的需求。要想和用户就业务问题进行交流，需求工程师应先具备能够和用户进行交流的知识基础，否则两者之间无法形成 有效的沟通。因此需求工程师需要先收集系统的背景资料以形成一个基础的知识框架，如企业 的业务状况等。如果需要对背景资料进行非常深入的了解（如进行产品线开发），就需要应用相 关的需求分析方法（如领域分析等）对收集的资料进行整合与处理，当然这是需求分析的任务。
在进行信息获取时，不同用户往往会从自身的立场出发考虑问题，提出相应的功能要求。这样，当软件系统涉及很多用户时常会发现用户相互之间对系统的期望有着很大的差距。因此，需要根据业务需求明确高层次的解决方案，确定软件产品未来的形式，定义项目的前景。有了共同的项目前景，不同的用户就可以从共同的方向上理解问题，提出对系统的功能要求。而且当用户之间发生需求冲突时，还可以利用项目前景指导需求冲突的协商解决。
需求获取中面对的信息内容非常广泛，因此，要保证获取的有效性，一方面要求不能在无关的内容上花费太大的代价，另一方面也要不遗漏应该获取的重要内容。因此在开展详细信息的 获取工作之前，应先根据业务需求确定项目的获取范围，然后在范围界限的指导下保证获取活动的正确和顺利进行。在项目开发后期发生需求变更时，还可以依据清晰的项目范围定义来排除不必要的变化请求。
获取的需求需要被编写成文档。业务需求被写入项目前景和范围文档，用户需求被写入用户需求文档（或用例文档），系统级需求被写入需求规格说明。
编写文档的主要目的是在系统涉众之间交流需求信息，因此编写的文档应该具有一定的质量。这些质量特性有些来自于文档内所有独立需求的质量之和，有些来自于编写者的写作技巧，最重要的质量要求是简洁、精确、一致和易于理解。
在需求开发活动之后，设计、测试、实现等后续的软件系统开发活动都需要围绕需求开展工 作“需求的影响力贯穿于整个软件的产品生命周期，而不是单纯的需求开发阶段。所以，在需求开发结束之后，还需要有一种力量保证需求作用的持续、稳定和有效发挥，需求管理就是这样的一个管理活动。
而且，在需求开发建立需求基线之后，还需要在设计、实现等后续活动中处理来自客户、管理 层、营销部门及其他涉众群体的变更请求。需求管理会进行变更控制，纳入和实现合理的变更请 求，拒绝不合理的变更请求，控制变更的成本和影响范围。
在任何一个知识领域中，人们都需要在进行相当的探索之后才能为其建立学科化和系统化的知识体系。这个探索的过程通常很漫长，很多自然科学领域的知识体系都是人们在进行了数 百或上千年的探索之后才逐渐形成的。
在工程领域中，如果能够建立比较完整的知识体系，那么就可以在知识体系的指导下进行规律性和系统化的生产。相反，在完全没有形成知识认知的全新工程领域中，就只能纯粹依赖生产者的个人才智来进行工作。也有介于上述两种情况之间的工程领域：它们还没有形成完整的知识体系，所以无法实现大工业化的生产方式；同时这些工程领域又经过了相当时间的探索，从生产者大量的个人行为中总结出了一些有效的工作方式和行为方法。这些有效的工作方式和行为 方法虽然比较琐碎和孤立，和知识体系的要求还有很大的距离，但是它们却能够很好地帮助人们更快更好地进行工程实践，所以被称为实践方法（practice；又被称为原则,principle）。

参考文献

需求工程——软件建模与分析第二版
[Jackson 1995a] JACKSON M. Problems and requirements, a keynote address at RE’ 95. Proceedings of the IEEE Second International Symposium on Requirements Engineering. ACM Press, 1995.
[Jackson 1995b] JACKSON M. The world and the machine, a keynote address at ICSE- 17. Proceedings of ICSE- 17. ACM Press, 1995.

应有内容建议

通过仔细阅读本书前几章内容，我对软件工程有了更深刻的认识。之所以被称为工程，因为他严谨，各个环节环环相扣，缺一不可。
不过在阅读过程中，较多的篇幅以及较多的举例，往往要花费更多精力去阅读。希望此书以后能够更加精简。