CH03信息系统分析（1）-概述

企业信息系统工程

第3章信息系统分析（1）——需求分析概述

温伯格名言：“明白自己在做什么”杰拉尔德·温伯格（GeraldM.Weinberg）是著名的软件和系统思想家，美国计算机名人堂代表人物。温伯格在软件与系统领域已经工作了45年。1997年，温伯格因其在软件领域的杰出贡献，被美国计算机博物馆的计算机名人堂选为首批5位成员之一。这个名人堂至今只有20名成员。为中国读者所熟悉的比尔·盖茨和迈克尔·戴尔等也是在他之后方才获得这一计算机界至高无上的殊荣。

这个书名意味什么？内容提要需求分析概述3.13.24过程建模3.3数据建模对象建模3.4学习目标学完本章后，你应该具备以下能力：理解什么是需求？需求有哪些层次？解释并判别什么是好的需求？理解需求分析的重要性。解释需求开发的步骤及每个步骤的工作内容。前导案例：用户与系统分析师之间的对话经理系统分析师“我们要建立一套完整的商业管理软件系统，包括商品的进、销、存管理，是总部-门店的连锁经营模式。通过通信手段门店自动订货，供应商自动结算，卖场通过条码扫描实现销售，管理人员能够随时查询门店商品销售和库存情况。”“我已经明白这个项目的大体结构框架，这非常重要，但在制定计划之前，我们必须收集一些需求。”经理“我不是刚告诉你我的需求了吗？”

经理觉得奇怪。前导案例：用户与系统分析师之间的对话“实际上，您只说明了整个项目的概念和目标。这些高层次的业务需求不足以提供开发的内容和时间。我需要与实际将要使用系统的业务人员进行讨论，然后才能真正明白达到业务目标所需功能和用户要求，了解清楚后，才可以发现哪些是现有组件即可实现的，哪些是需要开发的；才能决定采用是采用RDB还是OODB；才能决定……。”系统分析师经理“我不太明白你在说什么。另外，业务人员都非常忙，没有时间与你们详细讨论各种细节。你能不能说明一下你们现有的系统？”前导案例：用户与系统分析师之间的对话“如果我们只是凭空猜想用户的要求，结果不会令人满意。我们只是软件开发人员，而不是采购专家、营运专家或是财务专家，我们并不真正明白您这个企业内部运营需要做些什么。我曾经尝试过，未真正明白这些问题就开始编码，结果没有人对产品满意。”系统分析师尽量解释从用户处收集需求的合理性。系统分析师经理“行了，行了，我们没有那么多的时间。让我来告诉您我们的需求。实际上我也很忙。请马上开始开发，并随时将你们的进展情况告诉我。”案例问题：1.你认为经理对待需求方面，哪些态度和做法是错误的？哪些是值得肯定的？2.你认为系统分析师对待需求方面，哪些态度和做法是值得肯定的？哪些是错误的？前导案例：用户与系统分析师之间的对话

3.1需求分析概述系统分析(SystemAnalysis)是一个需求开发和管理的过程，是指运用一定的方法，对问题域和系统责任进行分析和理解，对其中的事物和它们之间的关系产生正确的认识，并产生一个符合用户需求，能够直接反映问题域和系统责任的模型及其详细说明。

3.1需求分析概述3.1.1什么是需求？需求(Requirement)是人们的期望。需求分析是寻找人们的期望的过程。需求分析的目的是试图找出人们对（待开发的）产品的期望。信息系统需求是指用户要求信息系统必须满足的所有功能和限制。需求包括：功能要求、性能要求、可靠性要求、安全保密性要求以及开发费用和开发周期、可使用资源等方面的限制。其中功能需求是最基本的,包括数据要求和加工要求。

信息系统需求包括三个不同的层次：业务需求、用户需求、功能需求和非功能需求。业务需求（businessrequirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。用户需求(userrequirement)文档描述了用户使用产品必须要完成的任务，这在用例（usecase）文档或方案脚本（scenario）说明中予以说明。

3.1.1什么是需求？功能需求(functionalrequirement)和非功能需求（non-functionalrequirements）功能需求定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。非功能需求是指性能要求、可靠性要求、安全保密性要求以及开发费用和开发周期、可使用资源等方面的限制。例如性能（吞吐量和响应时间）、易用性、预算、成本、进度、文档的编制和培训要求、质量管理要求、安全和内部审计控制等。

3.1.1什么是需求？“用户能有效地纠正文档中的拼写错误。”【例1】字处理程序的各种需求“找出文档中的拼写错误并通过一个提供的替换项列表来供选择替换拼错的词”。“找出拼写错误的词并高亮度显示；显示提供替换词的对话框；实现整个文档范围的替换。”

业务需求用户需求功能需求

3.1.1什么是需求？需求的特点：需求是隐性的。即连用户都不清楚自己的需求。需求是变化的。

3.1.1什么是需求？

3.1.2需求分析的重要性

国际著名的咨询公司StandishGroup著名的对350家公司的8000个软件项目的调研分析表明：1/3的项目在完成之前被取消；在大公司中，9%的项目超出预算或未能按时完成;在小公司中，只有16%的项目能够在预算范围内及时完成。【想一想为什么？】导致项目失败的原因:不完备的需求(13.1%)缺乏用户的参与(12.4%)缺少需要的资源(10.6%)不现实的期望(9.9%)缺乏高层领导的支持(9.3%)需求的变化(8.7%)缺乏计划(8.1%)系统不再需要(7.5%)哪些是与需求有关的？与需求有关的原因高达60.7%

3.1.2需求分析的重要性不正确的需求导致的后果：系统超出预算。系统延迟交付。系统不再满足用户的期望，导致用户不满意，系统被丢弃。一旦投入运行，要付出高昂的维护费用。失败导致用户不断抱怨IT人员。

3.1.2需求分析的重要性软件与系统思想家温伯格《探索需求——设计前的质量求设计编码单元测试验收测试维护需求——最值得改进的环节需求阶段的问题不解决，相当于在错误的方向上不断浪费人力物力

3.1.2需求分析的重要性研究性学习作业：调查研究报告：分析近年来国际知名咨询公司STANDISH的CHAOS报告，分析项目成功的要素。

3.1.2需求分析的重要性

3.1.3定义信息系统需求的标准（1）一致性（Consistent）:需求不应该是矛盾的、模糊的、二义的，每项需求对系统所有参与者而言都只能有一个明确统一的解释。可理解性是一致性的前提。即参加的各方应能以一种共同的方式来解释和理解需求。

建议：1.需求应尽可能详细2.尽可能用图表表达需求ManagementInterpretationI

TInterpretationUserInterpretation【思考】导致不一致的原因有哪些？如何避免需求的不一致性？【例】Createameanstotransportasingleindividualfromhometoplaceofwork.

3.1.3定义信息系统需求的标准（2）完备性:每一项需求都必须将所要实现的功能描述清楚，以使开发人员获得设计和实现这些功能所需的所有必要信息。应该表达所有系统风险承担者（Stakeholder）的需求。建议：1.认真检查I-P-O2.用例（UseCase)的思想

3.1.3定义信息系统需求的标准(3)必要性：所规定的需求必须是用户所需要的。建议：不要画蛇添足！

3.1.3定义信息系统需求的标准(4)可行性：每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。建议：为避免不可行的需求，最好在启发（elicitation）需求(收集需求)过程中始终有一位软件工程小组的成员与需求分析人员在一起工作，由他负责检查技术可行性。

3.1.3定义信息系统需求的标准(5)划分优先级。给每项需求、特性或用例分配一个实施优先级以指明它在特定产品中所占的分量。如果把所有的需求都看作同样重要，那么项目管理者在开发或节省预算或调度中就丧失控制自由度。建议：尊重用户的意见！

3.1.3定义信息系统需求的标准系统所有的功能必须能够在3次击键内完成。【测一测】你认为下面的需求描述有什么问题？

（1）系统应该是用户友好的.

（2）职工号必须在一个正确的范围内.职工号必须是整数且在1-32000之间。

（3）系统必须能够提供实时查询响应.系统必须提供实时查询响应且响应时间不超过2秒.

3.1.3定义信息系统需求的标准一些忠告：（1）用户参与程度不够导致产品无法接受;（2）用户需求的不断增加带来过度的耗费和降低产品的质量;（3）模棱两可的需求说明可能导致时间的浪费和返工;（4）用户增加一些不必要的特性和开发人员画蛇添足;（5）过分简略的需求说明以致遗漏某些关键需求;（6）忽略某类用户的需求将导致众多客户的不满;（7）不完善的需求说明使得项目计划和跟踪无法准确进行.

3.1.3定义信息系统需求的标准

3.1.4需求开发需求开发包括以下四个方面的活动：需求获取（Elicitation）需求分析(Analysis)编写规格说明（Specification）验证（Verification）。

3.1.4需求开发需求获取确定需求开发计划（确定如何组织需求的收集、分析、细化并核实的步骤）编写项目远景和范围文档（业务需求）用户群分类选择产品代表建立核心队伍确定用例（用户需求）召开应用程序开发联系会议分析用户工作流程确定质量属性检查问题报告需求重用

3.1.4.1需求获取SourcesofpossiblerequirementsElicitRequirements

CurrentorganizationandsystemsExistingdocumentsStakeholderwantsandneedsDomainmodelsCurrentsituationmodelReusablerequirementsSuggestedtypesofrequirementsRequirementstemplateReuselibrary【思考】结合本章的前导案例，分析讨论经理和系统分析师的需求沟通过程中存在哪些问题？

3.1.4.1需求获取需求抽取的方法一般有：问卷法面谈法数据采集法用况法情景实例法基于目标的方法知识工程方法，如：场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。

3.1.4.1需求获取确定需求开发计划（确定如何组织需求的收集、分析、细化并核实的步骤）编写项目视图和范围文档（业务需求）用户群分类选择产品代表建立核心队伍确定使用实例（用户需求）召开应用程序开发联系会议分析用户工作流程确定质量属性检查问题报告需求重用

3.1.4.1需求获取优秀的软件产品是建立在优秀的需求基础之上的。而高质量的需求来源于客户与开发人员之间有效的交流与合作。只有当双方参与者都明白要成功自己需要什么，同时也应知道要成功合作方需要什么时，才能建立起一种合作关系。

3.1.4.1需求获取沟通是一切

需求是一个过程，一个在软件生命周期中很重要的过程。在上一篇中，我们讨论了需求的层次、需求的风险、需求的特点。而在这么多需求要素之上的要素只有一个：沟通。沟通是什么，说小了是需求过程的重要技巧，说大了是软件企业的生命线。一个项目失败的原因有很多，而绝大多数都可以总结到沟通不畅。需求过程中充满了沟通：需求分析员和用户的沟通，不同的用户之间的沟通，需求分析员和需求审核人员的沟通，项目经理和需求分析员的沟通。沟通到一个什么程度，是需求成功与否的标志。

3.1.4.1需求获取需求分析绘制关联图（语境图）创建开发原型分析需求可行性确定需求优先级为需求建立模型编写数据字典应用质量功能调配

3.1.4.2需求分析

简单的说，需求分析就是依据某种建模方式对原始需求进行整理并文档化。

3.1.4.2需求分析绘制关联图绘制系统关联图是用于定义系统与系统外部实体间的界限和接口的简单模型。同时它也明确了通过接口的信息流和物流。

3.1.4.2需求分析创建开发原型创建用户接口原型当开发人员或用户不能确定需求时，开发一个用户接口原型，这样使得许多概念和可能发生的事更为直观明了。用户通过评价原型将使项目参与者能更好地相互理解所要解决的问题。注意要找出需求文档与原型之间所有的冲突之处。

3.1.4.2需求分析分析可行性分析需求可行性在允许的成本、性能要求下，分析每项需求实施的可行性，明确与每项需求实现相联系的风险，包括与其它需求的冲突，对外界因素的依赖和技术障碍。

3.1.4.2需求分析确定需求优先级确定需求的优先级别应用分析方法来确定使用实例、产品特性或单项需求实现的优先级别。以优先级为基础确定产品版本将包括哪些特性或哪类需求。当允许需求变更时，在特定的版本中加入每一项变更，并在那个版本计划中作出需要的变更。

3.1.4.2需求分析为需求建立模型：为需求建立模型需求的图形分析模型是软件需求规格说明极好的补充说明。它们能提供不同的信息与关系以有助于找到不正确的、不一致的、遗漏的和冗余的需求。这样的模型包括数据流图、实体关系图、状态变换图、对话框图、对象类及交互作用图。

3.1.4.2需求分析编写数据字典创建数据字典数据字典是对系统用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。在需求阶段，数据字典至少应定义客户数据项以确保客户与开发小组是使用一致的定义和术语。分析和设计工具通常包括数据字典组件。

3.1.4.2需求分析应用质量功能分配（QFD）使用质量功能调配质量功能调配是一种高级系统技术，它将产品特性、属性与对客户的重要性联系起来。该技术提供了一种分析方法以明确那些是客户最为关注的特性。它将需求分为三类：期望需求，即客户或许并未提及，但如若缺少会让他们感到不满意；普通需求；兴奋需求，即实现了会给客户带去惊喜，但若未实现也不会受到责备。

3.1.4.2需求分析编写需求规格说明书（SoftwareRequirementsSpecification,SRS）采用软件需求规格说明模版指明需求来源为每项需求注上标号建立需求跟踪能力矩阵

3.1.4.3编制需求规格说明书（SRS）软件需求规格说明书（SoftwareRequirementsSpecification,SRS）是需求工程在需求阶段的主要结果产品，它是软件系统外部行为和系统环境接口（软件、硬件、通讯端口和人）的简洁完整的描述文档[Davis88]。它可以由软件系统供应者（supplier），客户代表（customer）或两方联合编写，推荐的做法是两方联合完成SRS并都对其承担相应责任[IEEESTD830]。

3.1.4.3编制需求规格说明书（SRS）SRS的内容必须包括软件系统的功能性需求和非功能性需求。其中，软件系统的功能、外部接口属于功能性需求，也是系统需求的核心部分；软件系统的性能，可维护性，可扩展性，可靠性，安全性，设计和实现约束等则是非功能性需求。

3.1.4.3编制需求规格说明书（SRS）软件需求规格说明阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件,它不仅是系统测试和用户文档的基础，也是所有子系列项目规划、设计和编码的基础。它应该尽可能完整地描述系统预期的外部行为和用户可视化行为。除了设计和实现上的限制，软件需求规格说明不应该包括设计、构造、测试或工程管理的细节。

3.1.4.3编制需求规格说明书（SRS）采用软件需求规格说明模版采用需求规格说明书模板在你的组织中要为编写软件需求文档定义一种标准模板。该模板为记录功能需求和各种其它与需求相关的重要信息提供了统一的结构。注意，其目的并非是创建一种全新的模板，而是采用一种已有的且可满足项目需要并适合项目特点的模板。许多组织一开始都采用IEEE标准830-1998(IEEE1998)描述的需求规格说明书模板。要相信模板是很有用的，但有时要根据项目特点进行适当的改动。

3.1.4.3编制需求规格说明书（SRS）《需求规格说明书》模板第1章引言

1.1产品的目的

1.2文档约定

1.3风险承担者

1.4产品的范围

1.5参考文献第2章系统服务概述

2.1产品的前景

2.2产品的功能

2.3用户类和特征

2.4运行环境

2.5设计和实现上的限制

2.6假设和依赖第3章外部接口需求

3.1用户界面需求

3.2硬件接口

3.3软件接口

3.4通信接口第4章系统特性

4.1说明和优先级

4.2激励/响应序列

4.3功能需求第5章其它非功能需求

5.1性能需求

5.2安全设施需求

5.3安全性需求

5.4软件质量属性

5.5业务规则

5.6用户文档第6章其它方面的需求附录A：术语表附录B：分析模型附录C：业务文档和表格附录D：待确定问题的列表《需求规格说明书》模板SampleRequirementsDefinitionOutline1.正确性：正确性是相对于用户的应用需求而言的，是SRS首先需要保证的属性，即SRS中描述的需求都是软件系统真正需要完成或达到的。让用户对需求承担一定责任并和用户达成一致仍然可以在一定程度上满足正确性的要求。SRS必须满足的要求：

3.1.4.3编制需求规格说明书（SRS）2.无二义性：无二义性指SRS中陈述的需求只存在一种解释。由于这种解释需要被不同的人（例如用户和开发者）理解，所以一个困难是使用任何一方的术语都可能伤害另一方的理解程度。

3.1.4.3编制需求规格说明书（SRS）3.明确：自然语言（因为如果采用形式化语言的话，和用户的沟通将成为一个大问题，这意味着客户在开发软件之前必须先进行形式化语言培训，这是不现实的）。自然语言对需求分析最大的弊病就是它的二义性。所以我们不得不对需求分析中采用的语言做某些限制。例如尽量采用主语＋动作的简单表达方式。说白了，需求分析中的描述让人看上去像是刚学习写作的小孩子就对了，千万不要采用疑问句、修饰这些华丽的表达方式。除了语言的二义性之外，注意不要使用行话，就是计算机术语。否则就会造成用户理解上的困难。打个比方，如果你要做一个银行的信用卡系统，你就可以这样描述软件需求：银行的卡部管理信用卡，每张信用卡只属于一个帐户。信用卡有卡号、余额。一张信用卡有多笔的交易记录。

3.1.4.3编制需求规格说明书（SRS）4.完整性：完整性指任何有关软件系统功能性或非功能性的需求都包含在SRS中。广义来说，完整性指标是理想化的，因为主观意识存在模糊性和演化性。但狭义的说，完整性可以体现为对于所有已识别的外界输入，说明系统在所有情况下的输出，以及定义SRS中用到的所有术语。在迭代类开发模型中，达到狭义完整性要求就足够了。再也没有什么比软件开发接近完成时才发现遗漏了一项需求更糟的事情了。可是令人遗憾的是，需求的遗漏是很经常发生的事情，不仅仅是你的问题，更多的问题发生在用户那里，他们不知道该做些什么。

3.1.4.3编制需求规格说明书（SRS）4.完整性：

例子:如果A呼叫B并且B空闲，那么B的电话应该响铃。如果A呼叫B并且B空闲，那么除B的电话应该响铃以外其他所有的电话都不应该响。

3.1.4.3编制需求规格说明书（SRS）5.一致性：一致性指SRS中描述的需求不能有内部冲突。简单的来说，就是用户需求必须和业务需求一致，功能需求必须和用户需求一致。严格的遵守不同层次间的一致性关系，就可以保证最后开发出来的软件系统不会偏离最初的实现目标。在实现过程中，我们还必须把一致性关系细化。比如说用户需求不能超出先前指定的范围。例如某个输入项在一个需求项中被指定为从一个全集里枚举，而在另一处则被指定为文字输入。 例子：在SRS中一个地方规定“只有当系统输入B发生时系统输入A才能发生”，而在另一个地方却规定“系统输入A发生15秒后系统输入B可以发生”

3.1.4.3编制需求规格说明书（SRS）6.优先级（稳定性）：优先级表明需求对于软件系统的重要程度，而稳定性指出需求的变更可能性大小。给需求指定优先级（或稳定性）有助于帮助用户更细致的考虑自己的想法，并能帮助开发者对系统设计做出合理的安排和权衡。以给客户带来最大利益的需求为最高优先级。如果用户没有提出，那么项目经理必须作出正确决断。（价值、费用、风险）

3.1.4.3编制需求规格说明书（SRS）7.可验证性：可验证性指SRS中表述的需求都在系统实现后可验证，即存在某种客观的标准判定系统是否满足该需求。

项目的测试从什么时候开始？实际上，测试是从需求分析过程就开始了。需求分析是测试计划的输入和参照。这就要求需求分析是可测试的。什么是可测试呢？例子："我们要用新的系统完成报表自动化处理"，你觉得这个需求是可测试的吗？当然不是，报表包括哪些？自动化处理的标准是什么？这些在需求中都没有说明。因此这项需求是无法测试的，就是不具有可测试性。

3.1.4.3编制需求规格说明书（SRS）7.可验证性：可验证性指SRS中表述的需求都在系统实现后可验证，即存在某种客观的标准判定系统是否满足该需求。

例子：“系统必须非常迅速的对Button2被按下做出反应”就是不可验证的需求，而“系统必须在0.1秒之内显示Button2被按下的处理结果”就是可验证的。

3.1.4.3编制需求规格说明书（SRS）8.可修改性：可修改性指需求发生变更时SRS必须能够容易的被完整、一致的修改。这一般要求SRS按清晰的方式组织，没有冗余（或冗余被明确标记）和独立需求尽量分开陈述而不是混在一起。SRS的格式和组织方式（文档结构和风格）容易修改。

3.1.4.3编制需求规格说明书（SRS）9.可跟踪性：要求每一个需求的来源及流向必须是清晰的。可跟踪性指SRS中描述的需求能够方便的找到来源并被后续开发方便的检索和引用。这里包含了两层意思：反向可跟踪性和正向可跟踪性。反向可跟踪性指SRS中的需求需要标记从哪个更早期的文档获得；正向可跟踪性要求对SRS中需求进行编号以进行检索和引用。

3.1.4.3编制需求规格说明书（SRS）测验题：例1．“产品应在不少于每60秒的正常周期内提供状态信息”

3.1.4.3编制需求规格说明书（SRS）这个需求是不完整的。状态信息是什么，如何显示给用户。这个需求有几处含糊。我们在谈论产品的哪部分？状态信息间隔真的假定为不少于60秒？，甚者每10年显示一条新的状态信息也可以？也许它的意图是消息间隔不应超过60秒，那么1毫秒是不是太短？“每”这个词导致了不确定性。问题的后果，就是需求的不可证实。

3.1.4.3编制需求规格说明书（SRS）弥补缺陷，重写需求的一种方法：1、状态信息

1．1后台任务管理器应该以误差上下不超过10秒的60秒间隔，在用户界面的指定位置显示状态信息

1．2如果后台进程处理正常，那么应该显示任务已完成的百分数/比

1．3任务完成时，应显示相关的信息

1．4后台任务出错应该显示错误信息

为了分别测试和追踪，我将其分成了多个需求。如果将几个需求串接在一节中，在构造和测试时就很容易漏掉一个。

3.1.4.3编制需求规格说明书（SRS）例2．“产品应瞬间在显示和隐藏不可打印字符间切换”

3.1.4.3编制需求规格说明书（SRS）计算机在瞬间不能做任何事，所以这个需求不切实可行。它的不完整性表现在没有声明触发状态切换的条件。软件要在某些条件下更改自己？或者用户为了模仿更改要做一些动作？而且，在文档中改变显示的范围是多大：选中的文本，整个的文档，或其他的？这也是个模糊的问题。不可打印字符和隐藏字符一样吗？或者是一些属性标志或一些控制字符？问题的后果，就是需求的不可证实。

3.1.4.3编制需求规格说明书（SRS）象这样编写需求也许更好一些：“用户能够在一个由特定触发条件激活处于编辑的文档中在显示和隐藏所有HTML标记间切换”。现在就很清楚，不可打印字符是HTML标记。由于没有定义触发条件，需求对设计没有约束力。只有设计人员选定了触发条件后，你才能编写测试验证触发的正确操作。

3.1.4.3编制需求规格说明书（SRS）例3．“HTML分析器可以产生HTML标记错误报告，帮助HTML入门者快速解决错误”。

3.1.4.3编制需求规格说明书（SRS）单词“快速”使其模糊，没有加进错误报告的定义也是其部完整。我不知道，你怎么验证这个需求。找一个自称为HTML的入门者，看看能不能根据错误报告快速解决错误？

3.1.4.3编制需求规格说明书（SRS）试试这个：

“HTML分析器可以产生一个错误报告，错误报告包含有在被分析文件中出错的HTML文本和行号以及错误的描述。如果没有错误，就不会产生错误报告”。 现在我们知道了，什么会被加到出错报告中，但是出错报告是个什么样子，则留由设计人员决定。我们还指定了一个例外：如果没有发现错误，不产生错误报告。

3.1.4.3编制需求规格说明书（SRS）例4．“如果可能，主管号码应通过联机校验，而不是通过主全体主管号码列表校验”。

3.1.4.3编制需求规格说明书（SRS）真感到绝望，什么是“如果可能”：如果技术上可行？如果主全体主管号码列表可以联机获得？要避免象“应该”的这类不确切的词。客户是需要这个功能性还是不需要。我曾看过一些需求说明书，采用诸如：应，将，应该/将要等一些词描述优先级的细微差别。但我更喜欢用“应”清楚的说明需求的意图，指明优先级。

3.1.4.3编制需求规格说明书（SRS）修改后：系统应校验输入的主管号码而不通过联机的主全体主官号码列表。如果在列表中没有发现主管号码，将会显示一条错误信息，也不接受指令。

3.1.4.3编制需求规格说明书（SR