下载掌阅APP，畅读海量书库
立即打开
范围计划是项目计划很重要的一部分，本章进入路线图的“范围计划”，如图4-1所示。
图4-1 项目计划—范围计划：需求管理
项目范围管理是对项目包括什么与不包括什么的定义与控制过程。确定项目范围是制订软件计划的依据，包括对功能、性能、接口和可靠性的确定。通过项目范围管理，明确项目管理的目标与边界。
在范围管理中首先要定义项目的范围，它是项目实施的依据和变更的输入，只有对项目的范围进行明确的定义，才能进行有效的项目规划。项目目标必须是可实现、可度量的，这一步管理不好会导致项目的最终失败。项目范围是指开发项目产品所包括的工作及产生这些产品所用的过程。项目人员必须在项目要产生什么样的产品方面达成共识，也要在如何生产这些产品方面达成共识。这个过程规定了如何对项目范围进行定义、管理和控制。项目的规模、复杂度、重要性等因素决定了范围计划的工作量，不同的项目，范围计划的情况可以不同，而软件项目的范围首先从项目的需求开始。
无论采用何种软件生存期模型，软件需求是软件开发过程的基础，是软件项目建设的基石。资料表明，软件项目中40%～60%的问题都是在需求分析阶段埋下的隐患。软件开发中返工开销占开发总费用的40%，而其中70%～80%的返工是由需求方面的错误所导致的。在以往失败的软件项目中，80%是由于需求分析的不明确而造成的。因此一个项目成功的关键因素之一就是对需求分析的把握程度，而项目的整体风险往往是由需求分析不明确、业务流程不合理造成的，所以需求管理是项目管理的重要一环。
软件需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情，完成什么样的功能、达到什么样的性能。软件设计人员要准确理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义转化到相应形式的需求规约。对于软件项目的需求，首先要理解用户的要求，澄清模糊的需求，与用户达成共识。
软件需求包括三个不同的层次：业务需求（business requirement）、用户需求（user requirement）、功能需求（functional requirement）。最后确定软件需求规约（Software Requirement Specification，SRS），它们的关系如图4-2所示。
业务需求反映了组织机构或客户对系统、产品高层次的目标要求，由管理人员或市场分析人员确定，在项目视图与范围文档中予以说明。用户需求描述了用户通过使用本软件产品必须要完成的任务，一般由用户协助提供。用户需求可以在用例（use case）或场景（scenario）说明中予以说明。
图4-2 软件需求的层次
功能需求定义了开发人员必须实现的软件功能，使得用户通过使用此软件能完成他们的任务，从而满足业务需求。对于复杂产品来说，功能需求也许只是系统需求的一个子集。软件需求规约充分描述了软件系统应具有的外部行为，描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约，外部界面的具体细节，非功能性需求（如性能要求等），设计或实现的约束条件及质量属性。约束是指对开发人员在软件产品设计和构造上的限制。质量属性通过多种角度对产品的特点进行描述，从而反映产品功能。多角度描述产品对用户和开发人员都极为重要。
软件需求规约说明在开发、测试、质量保证、项目管理以及相关项目功能中都起着重要的作用。
用户需求必须与业务需求一致。用户需求使需求分析者能从中总结出功能需求，以满足用户对产品的期望从而完成任务，而开发人员根据软件需求规约来设计软件，以实现必要的功能。
软件需求是软件开发项目中最关键的一个输入，与传统行业相比，软件的需求具有模糊性、不确定性、变化性和主观性的特点。需求获取是指通过与用户的交流、对现有系统的观察及对任务的分析，开发、捕获和修订用户的需求。正确获取用户需求不是一件容易的事情，我们以为互相了解彼此的需求，但是常常是“我以为的其实不是你以为的”（如图4-3所示）。而且对于同样的需求，不同的人又有不同的理解和描述，客户自己描述需求时也未必能够将自己的实际想法描述清楚（如图4-4所示）。因此，需求获取是一项很重要也很困难的任务。
图4-3 我以为的其实不是你以为的
图4-4 不同角色对需求的描述
需求获取的主要任务是与用户方的领导层、业务层人员进行访谈式沟通，目的是从宏观上把握用户的具体需求方向和趋势，了解现有的组织架构、业务流程、硬件环境、软件环境、现有的运行系统等具体情况和客观信息，建立良好的沟通渠道和方式。
需求获取需要执行的活动如下。
1）了解客户方的所有用户类型以及潜在的类型，然后根据他们的要求来确定系统的整体目标和系统的工作范围。
2）进行需求调查，对用户进行访谈和调研。交流的方式可以是会议、电话、电子邮件、小组讨论、模拟演示等不同形式。需要注意的是，每一次交流一定要有记录，还可以对交流的结果进行分类，便于后续的分析活动。需求调查说明如下。
· 面对面的沟通。与用户就需求问题进行一对一的面对面沟通是最有效的方式。电子邮件Q&A列表是向用户调查需求的主要方式，对于软件产品需求不明确的问题，可整理归纳成Q&A列表，通过电子邮件传递给用户。Q&A列表能够详细记录问题从不明确到清晰的整个过程，但是比较费时，需求提问的进度取决用户是否能及时答复邮件。
· 电视电话会议访谈。电视电话会议访谈是一种自由的、开放的获取需求的方式，可以深入探究用户对某些问题的回答，从而得到更准确的信息。对不同的被访谈者可以及时调整问话方式，但是需要注意沟通方式。
· 需求专题讨论会。需求专题讨论会即头脑风暴（brain storm），它是指在一段短暂但紧凑的时间段内，把所有与需求相关的人员集中到一起，围绕产品或者项目的目标进行自由讨论，各抒己见，最后统一归纳出初步的需求。这种方式的效率非常高，看上去不相关的意见经过综合往往可以得出很好的主意，并且可以立即得出结果，但是需要有经验的人组织才能保证成功。
· 自行搜集需求。客户不能提供明确的需求，需要我们自己调查相关的行业标准、同类标准，总结出功能、非功能需求。
3）需求分析人员对收集到的用户需求做进一步的分析和整理。
对于用户提出的每个需求都要知道“为什么”，并判断用户提出的需求是否有充足的理由。将“如何实现”的表述方式转换为“实现什么”的方式，因为需求分析阶段关注的目标是“做什么”，而不是“怎么做”。
分析由用户需求衍生出的隐含需求，并识别用户没有明确提出的隐含需求（有可能是实现用户需求的前提条件）。这一点往往容易被忽略，经常因为对隐含需求考虑得不够充分而引起需求变更。
4）需求分析人员将调研的用户需求以适当的方式呈交给用户方和开发方的相关人员。大家共同确认需求分析人员所提交的结果是否真实地反映了用户的意图。需求分析人员在这个任务中需要执行下述活动。
· 明确标识出那些未确定的需求项（在需求分析初期往往有很多这样的待定项）。
· 使需求符合系统的整体目标。
· 保证需求项之间的一致性，解决需求项之间可能存在的冲突。
综上所述，进行需求获取的时候应该注意如下问题。
· 识别真正的客户。识别真正的客户不是一件容易的事情，项目总是要面对多方的客户，不同类型客户的素质和背景都不一样。有时他们没有共同的利益，例如，销售人员希望使用方便、会计人员最关心的是销售的数据如何统计、人力资源关心的是如何管理和培训员工等。有时他们的利益甚至有冲突，所以必须认识到客户并非平等的，有些人比其他人对项目的成功更为重要。我们需要清楚地认识影响项目的客户，并对多方客户的需求进行排序。
· 正确理解客户的需求。客户有时并不十分明白自己的需要，可能提供一些混乱的信息，而且有时会夸大或者弱化真正的需求。所以我们既要懂一些心理学知识，也要懂一些其他行业的知识，了解客户的业务和社会背景，有选择地过滤需求，理解和完善需求，确认客户真正需要的东西。例如，除了表面的需求，客户个体其实还有隐含的“需要”。
· 具备较强的忍耐力和清晰的思维。进行需求获取的时候，应该能够从客户凌乱的建议和观点中整理出真正的需求，不能对客户需求的不确定性和过分要求失去耐心，甚至造成不愉快，要具备良好的协调能力。
· 说服和教育客户。需求分析人员可以同客户密切合作，帮助他们找出真正的需求，可以通过说服引导等手段，也可以通过培训来实现。同时要告诉客户需求可能会不可避免地发生变更—这些变更会给持续的项目正常化增加很大的负担，使客户认真对待变更。
· 需求获取阶段一般需要建立需求分析小组，进行充分交流，互相学习，同时要实地考察访谈，收集相关资料，进行语言交流，必要时可以采用图形表格等工具。
需求分析也称为需求建模，是指为最终用户所看到的系统建立一个概念模型，是对需求的抽象描述，并尽可能多地捕获现实世界的语义。需求分析的任务是借助于当前系统的逻辑模型导出目标系统的逻辑模型，解决目标系统“做什么”的问题，如图4-5所示。
图4-5 需求分析模型
需求分析是项目成功的基础，应得到足够的重视，还要为其分配充足的时间和人力，让有经验的系统分析员负责，切忌让项目新手或程序员负责。最好让用户参与需求分析过程，如果条件不允许，在选择参与的用户时，一方面，要尽可能争取精通业务或计算机技术的用户参与，另一方面，如果开发的产品要在不同规模、不同类型的企业应用，应该选择具有代表性的用户参与。
需求是与技术无关（technology independent）的。在需求阶段讨论技术是没有任何意义的，只会分散你的注意力。技术的实现细节是在后面的设计阶段才需要考虑的事情。在很多情形下，分析用户需求是与获取用户需求并行的，主要通过建立模型的方式来描述用户的需求，为客户、用户、开发方等不同参与方提供一个交流的渠道。这些模型是对需求的抽象，以可视化的方式提供一个易于沟通的桥梁。需求分析与需求获取有着相似的步骤，区别在于分析用户需求时使用模型来描述，以获取更明确的需求。
需求分析应该执行下面的活动。
· 以图形表示的方式描述系统的整体结构，包括系统的边界与接口。
· 通过原型、页面流或其他方式向用户提供可视化的界面，用户可以对需求做出自己的评价。用户通常不善于精确描述自己的业务需求，系统分析员需要借助白板、白纸等沟通方式帮助用户清楚地表述需求，然后，开发一个用户界面原型，以便用户确认需求。
· 以模型描述系统的功能项、数据实体、外部实体、实体之间的关系、实体之间的状态转换等方面的内容。
需求分析的基本策略是采用头脑风暴、专家评审、焦点会议组等方式进行具体的流程细化、数据项的确认，必要时可以提供原型系统和明确的业务流程报告、数据项表，并能清晰地向用户描述系统的业务流设计目标。用户方可以通过审查业务流程报告、数据项表以及操作开发方提供的原型系统来提出反馈意见，并对可接受的报告、文档签字确认。
对于客户表达的需求，不同的分析人员可能有不同的理解。如果分析人员对客户需求理解有误，可能会导致以后的开发工作劳而无功。所以，进行需求分析的时候，要求开发人员具有广泛的知识面。
对于软件这个特殊领域的业务需求，项目经理在管理需求的时候，一定要求需求分析人员首先获取用户的真正需求，即使是双方画的简单的流程草案也很重要，然后根据获取的真正需求采用适当的方法编写需求规约。
软件需求规约的编制是为了使用户和软件开发者双方对该软件的初始规定有共同的理解，使之成为整个开发工作的基础。需求分析完成的标志是提交一份完整的软件需求规约（SRS）。建立了需求规约，才能描述要开发的产品，并作为项目演化的指导。如果没有需求规约，那么需求将隐含地确定及影响项目的内容和项目的成功。需求规约以一种开发人员可用的技术形式陈述了一个软件产品所具有的基本特征和性质，以及期望和选择的特征和性质。对于项目来说，需求规约和工作陈述（Statement Of Work，SOW）是很关键的两个文档，需求规约的编写可以参照甲方提供的工作陈述的有关信息，它为客户和开发者之间建立一个约定，准确地陈述了要交付给客户什么。
软件产品范围是指软件产品所包含的特征或功能，而软件需求规约正是对软件产品范围正式且书面的界定，是软件项目管理过程必需的基础性文档。需求规约相当于软件开发的图纸，一般地，软件需求规约的格式可以根据项目的具体情况而定，没有统一的标准。
有一种非常危险的思想，即在项目的需求分析阶段，开发方与客户方在各种问题的基本轮廓上达成一致即可，具体细节可在以后补充。实际上许多软件项目失败的最主要的原因就是需求阶段对问题的描述不够细致，导致后来超出预算或者时间进度无法达到要求。正确的做法是：在项目需求分析阶段，双方必须全面地、尽可能细致地讨论项目的应用背景、功能要求、性能要求、操作界面要求、与其他软件的接口要求，以及对项目进行评估的各种评价标准，并且在需求分析结束以后，双方还要建立可以直接联系的渠道，以尽早地针对需求变动问题进行沟通。
提交需求规约后，开发人员需要与客户对需求分析的结果进行验证，以需求规约为输入，通过符号执行、模拟或快速原型等途径，分析需求规约的正确性和可行性，以使需求规约中定义的需求正确、准确地反映用户的意图。
验证需求的正确性及其质量能大大减少项目后期的返工现象。在项目计划中应为这些保证质量的活动预留时间并提供资源。从客户代表方获得参与需求评审的赞同（承诺），并尽早且以尽可能低的成本，通过从非正式的评审逐渐到正式评审来找出其存在的问题。
需求验证包括以下几个方面。
· 需求的正确性。开发人员和用户都进行复查，以确保将用户的需求充分、正确地表达出来。只有通过调查研究，才能知道某一项需求是否正确。每一项需求都必须准确地陈述其要开发的功能。做出正确判断的参考是需求的来源，如用户或高层的系统需求规约说明书。若软件需求与对应的系统需求相抵触，则是不正确的。只有用户代表才能确定用户需求的正确性，这是一定要有用户积极参与的原因。没有用户参与的需求评审将导致评审者凭空猜测。
· 需求的一致性。一致性是指与其他软件需求或高层（系统、业务）需求不相矛盾。在开发前必须解决所有需求间的不一致部分。验证没有任何的冲突和含糊的需求，没有二义性。
· 需求的完整性。验证是否所有可能的状态、状态变化、转入、产品和约束都在需求中描述，不能遗漏任何必要的需求信息，因为很难查出遗漏的需求。注重用户的任务而不是系统的功能有助于避免不完整性。如果知道缺少某项信息，用TBD（待确定）作为标准标识来标明这项缺漏。在开始开发之前，必须解决需求中所有的TBD项。
· 需求的可行性。验证需求是否实际可行，每一项需求都必须是在已知系统和环境的权能和限制范围内可以实施的。为避免不可行的需求，最好在获取需求（收集需求）过程中始终有一位软件工程小组的组员与需求分析人员或市场人员在一起工作，由他负责检查技术可行性。
· 需求的必要性。验证需求是客户需要的，每一条需求描述都是用户需要的，每一项需求都应把客户真正所需要的和最终系统需要遵从的标准记录下来。必要性也可以理解为每项需求都是用来授权你编写文档的“根源”。要使每项需求都能回溯至某项客户的输入。
· 需求的可检验性。验证是否能写出测试案例来满足需求，检查每项需求是否能通过设计测试用例或其他的验证方法，如用演示、检测等来确定产品是否确实按需求实现了。如果需求不可验证，则确定其实施是否正确就成为主观臆断，而非客观分析。一份前后矛盾、不可行或有二义性的需求也是不可验证的。有的项目范围的定义不够明确，做不到量化，可验证程度不高，很多时候都是一些定性而不是定量的要求，如“界面友好，可操作性强，提高用户满意度”等。这些模糊的需求是导致后续项目“扯皮”的根源。对于项目范围的明确定义，有经验的项目经理及系统分析员起着至关重要的作用。
· 需求的可跟踪性。验证需求是否是可跟踪的，应能在每项软件需求与它的根源和设计元素、源代码、测试用例之间建立链接，这种可跟踪性要求每项需求以一种结构化的、细粒度的方式编写并单独标明，而不是大段的叙述。软件开发的基本目标是构造能够满足客户基本需求的软件系统，因此需要一种检测手段来检验软件是否满足所有的需求。需求跟踪是一种有效的检测手段，要求对每一项需求都可以追踪到实现该需求的设计、编码及测试用例。通过需求追踪，可以检验软件是否实现了所有需求以及软件是否对所有的需求都经过了测试。有两种类型的跟踪：前向跟踪和后向跟踪。前向追踪意味着看需求是否在生命周期的后续阶段（如设计和编码阶段）的工作成果中得到体现，后向追踪意味着看生命周期后期的各个阶段的工作成果满足何种需求，前向追踪保证了软件能够满足需求，后向追踪则在变更、回归测试等情况下更有用。因此可以在项目进行过程中采用需求跟踪矩阵来管理项目需求。
· 最后的签字。通过评审的需求规约，要让用户方签字，并作为项目合同的附件，对双方都具有约束力。
需求变更是软件项目一个突出的特点，也是软件项目最为普遍的一个特点。做过软件项目的人可能会有这样的经历：一个项目做了很久，感觉总是做不完，就像一个“无底洞”。虽然这与人类认识问题的自然规律是一致的，但是频繁而无管理的需求变更非常容易导致复杂、无形的软件在多变的情况下失控，增加软件开发过程中的不稳定性，从而造成多方的损失。据相关数据统计，需求变更是导致项目失败的主要原因之一。那么如何对需求变更加以有效的控制和管理，从而保证软件开发的进度、成本和质量，便成为软件开发过程中一个值得思考的问题。
客户的需求为什么一变再变？人类认识世界是一个由无知到已知、由浅入深的过程，我们以及客户对需求的认识也是一个逐步深入、逐步明晰的过程。随着认识的深入，客户的需求才逐渐明确。软件人员在最初的时候需要帮助客户深化认识、明确需求。
引起需求变更的表现形式是多样的，例如，客户改变想法、项目预算发生变化或者客户对某些功能的改变。在软件开发项目中，需求变更可能来自各个方面，如客户、方案服务商或产品供应商，也可能来源于项目组内部。
在软件开发过程中，需求的变更会给开发带来不确定性，所以必须接受“需求会变动”这个事实，做好需求变更的管理工作。需求变更管理主要的工作如下。
· 建立需求基线。需求基线是需求变更的依据。在开发过程中，需求确定并经过评审后（用户参与评审），可以建立第一个需求基线。此后每次变更并经过评审后，都要重新确定新的需求基线。
· 确定需求变更控制过程。制定简单、有效的变更控制流程，并形成文档。在建立需求基线后提出的所有变更必须遵循变更控制流程进行控制。
· 建立变更控制委员会（SCCB）。成立SCCB或相关职能的类似组织，负责裁定接受哪些变更。SCCB由项目所涉及的多方人员共同组成，应该包括用户方和开发方的决策人员在内。
· 进行需求变更影响分析。需求变更一定要先申请然后评估，最后经过与变更大小相当级别的评审确认。对于提交的每项需求变更请求，应确定其对项目整体进度的影响和对其他相关开发任务的影响，并且一定要明确完成这些变更相关任务的工作量。只有经过全面的分析，SCCB才能够做出更好的决策。
· 跟踪所有受需求变更影响的工作产品。需求变更后，受影响的软件计划、产品、活动都要进行相应的变更，以保持和更新的需求一致。
· 建立需求基准版本和需求控制版本文档，维护需求变更的历史记录。妥善保存变更产生的相关文档。记录每个需求变更文档的版本号、日期、所做的变更、原因等，并应该明确该文档由谁来负责更新。
· 跟踪每项需求的状态，衡量需求稳定性。SCCB需要对需求变更的整体有良好的把握，通过记录需求基准的数量可以获得宏观需求的变更次数，同时应该记录一段时间内（如每周、每月）的变更数量，最好按变更的类别来列出详细信息。如果某一需求过于频繁变更，则说明对该问题的认识还不深入或者还没有达成一致的处理意见。如果需求变更的总体数量过高，则意味着项目范围并未很好地确定下来或是政策变化较大。
并非对需求定义得越详细，越能避免需求的渐变，这是两个层面的问题。太细的需求定义对需求渐变没有任何效果，因为需求的变化是永恒的，并非由于需求写得详细了，它就不会变化了。图4-6是需求变更管理流程图，包括需求提交阶段、需求受理阶段、需求规划分析阶段、需求实施阶段等。
图4-6 需求变更管理流程图
结构化分析（Structured Analysis，SA）方法是20世纪70年发展起来的最早的开发方法，其中有代表性的是美国Coad/Yourdon的面向数据流的开发方法、欧洲Jackson/Warnier-Orr的面向数据结构的开发方法，以及日本小村良彦等人的PAD开发方法，尽管当今面向对象开发方法兴起，但是如果不了解传统的结构化方法，就不可能真正掌握面向对象的开发方法，因为面向对象开发方法中的操作仍然以传统的结构化方法为基础，结构化方法是很多其他方法的基础。
结构化分析方法将现实世界描绘为数据在信息系统中的流动，以及数据在流动过程中向信息的转化，帮助开发人员定义系统需要做什么、系统需要存储和使用哪些数据、系统需要什么样的输入和输出，以及如何将这些功能结合在一起来完成任务。
结构化方法为进行详细的系统建模提供了框架，很多的结构化模型有一套自己的处理规则。结构化分析方法是一种比较传统、常用的需求分析方法，采用结构化需求分析，一般会采用结构化设计（Structured Design，SD）方法进行系统设计。结构化分析和结构化设计是结构化软件开发中最关键的阶段。
数据流图（Data Flow Diagram，DFD）、系统流程图等都属于结构化分析技术。
1.数据流图方法
数据流图作为结构化系统分析与设计的主要方法，直观地展示了系统中的数据是如何被加工处理和流动的，是一种广泛使用的自上而下的方法。数据流图采用图形符号描述软件系统的逻辑模型，使用四种基本元素来描述系统的行为，它们是过程、实体、数据流和数据存储。数据流图直观易懂，使用者可以方便地得到系统的逻辑模型和物理模型，但是从数据流图中无法判断活动的时序关系。
数据流图已经得到了广泛的应用，尤其适用于管理信息系统（MIS）的表述。图4-7是一个旅行社订票过程的数据流图，它描述了从订票到得到机票，到最后将机票给旅客的数据流动过程，其中包括查询航班目录、费用的记账等过程。
确定数据流图后，还需要确定每个数据流和变化（加工）的细节，也就是数据字典和加工说明，这是一个很重要的步骤，是软件开发后续阶段的工作基础。
对于较为复杂问题的数据处理过程，用一个数据流图往往不够，一般按问题的层次结构进行逐步分解，并以分层的数据流图反映这种结构关系。根据层次关系，通常将数据流图分为顶层数据流图、中间数据流图和底层数据流图。对于任何一层数据流图来说，称它的上一层数据流图为父图，称它的下一层数据流图为子图。
· 顶层数据流图只含有一个加工，表示整个系统。输入数据流和输出数据流为系统的输入数据和输出数据，表明了系统的范围以及与外部环境的数据交换关系。
图4-7 订票过程数据流图
· 底层数据流图是指其加工不能再分解的数据流图，其加工称为“原子加工”。
· 中间数据流图是对父层数据流图中的某个加工进行细化，而它的某个加工也可以再次细化，形成子图。中间层次的多少，一般视系统的复杂程度而定。
· 任何一个数据流子图必须与它上一层父图的某个加工对应，两者的输入数据流和输出数据流必须保持一致，此即父图与子图的平衡。父图与子图的平衡是数据流图中的重要性质，保证了数据流图的一致性，便于分析人员阅读和理解。
在父图与子图平衡中，数据流的数目和名称可以完全相同，也可以在数目上不相等，但是可以借助数据字典中的数据流描述，确定父图中的数据流是由子图中几个数据流合并而成的，即子图是对父图中的加工和数据流同时进行分解，因此也属于父图与子图的平衡，如图4-8所示。
图4-8 父图与子图的平衡
一个加工的所有输出数据流中的数据必须能从该加工的输入数据流中直接获得，或者是通过该加工能产生的数据。每个加工必须有输入数据流和输出数据流，反映此加工的数据来源和加工变换结果。一个加工的输出数据流只由它的输入数据流确定。数据流必须经过加工，即必须进入加工或从加工中流出。
数据字典描述系统中涉及的每个数据，是数据描述的集合，通常配合数据流图使用，用来描述数据流图中出现的各种数据和加工，包括数据项、数据流、数据文件等。其中，数据项表示数据元素，数据流是由数据项组成的，数据文件表示对数据的存储。
2.系统流程图
系统流程图是一种表示操作顺序和信息流动过程的图表，是描述物理系统的工具，其基本元素或概念用标准化的图形符号来表示，相互关系用连线表示。流程图是有向图，其中每个节点代表一个或一组操作。
在数据处理过程中，不同的工作人员使用不同的流程图。大多数设计单位、程序设计人员之间进行学术交流时，都习惯用流程图表达各自的想法。流程图是交流各自思想的一种强有力的工具，其目的是把复杂的系统关系用一种简单、直观的图表表示出来，以便帮助处理问题的人员更清楚地了解系统，也可以用它来检查系统的逻辑关系是否正确。
绘制流程图的法则是优先关系法则，其基本思想是：先把整个系统当作一个“功能”来看待，画出最粗略的流程图，然后逐层向下分析，加入各种细节，直到达到所需要的详尽程度为止。
利用一些基本符号，按照系统的逻辑顺序以及系统中各部分的制约关系绘制成的一个完整图形，就是系统流程图。系统流程图的设计步骤如下。
1）分析实现程序必需的设备。
2）分析数据在各种设备之间的交换过程。
3）用系统流程图或程序流程图的基本符号描述其交换过程。
图4-9采用系统流程图描述了外事部门出访业务需求。
图4-9 外事部门出访业务需求系统流程图
进行需求建模时，首先根据分析目标，确定系统的角色，即参与者，然后确定相应的用例。用例在需求分析中的作用是很大的，它从用户的角度，而不是程序员的角度看待系统，因此用例驱动的系统能够真正做到以用户为中心，用户的任何需求都能够在系统开发链中完整地体现。用户和程序员间通过用例沟通会很方便。从前，系统开发者总是通过情节来获取需求，问用户“希望系统为他做什么”。通过用例需求分析方法，需求获取就变成问用户“要利用系统做什么”。这是立场不同导致的结果。用户通常并不关心系统是如何实现的，对于他们来说，更重要的是要达到他们的目的。相反，大部分的程序员的工作习惯就是考虑计算机应该如何实现用户的要求。所幸的是，用例方法能够调和双方的矛盾，因为虽然用例来源于用户，服务于用户，但是它同样可以用于开发的流程。
下面以某进出口贸易项目的需求分析为例，说明采用UML方法建立需求模型的基本步骤。
1.分析目标
通过需求分析，确定项目目标，定义系统特征。进出口贸易的业务环节很多，涉及配额与许可申请、询价、报价、合同洽谈、备货（出口）、信用证、商检、报关、运输、投保、付汇/结汇、出口核销退税等多个环节，并分别隶属于外贸、内贸、生产部门、海关、商检、银行、税务、保险、运输等职能机构和业务主管部门。这种跨部门、跨单位的“物流”过程，同样伴随着十分复杂的“信息流”。在实际业务中，不同的交易，不同的交易条件，其业务内容和处理过程也不尽相同。在具体运作方面，贸易处理程序及产生的单证交换，又常常是“并发”与“顺序”交叉进行的。贸易程序的简化一直是贸易效率化和低成本交易的“瓶颈”。
2.确定角色（参与者）
角色即参与者，是指在系统之外，与系统进行交互的任何事物，在此处指用户在系统中所扮演的角色，如此模型中，出口商即为一个参与者，参与者与用例的关系描述了“谁使用了那个用例”。进出口贸易涉及的参与者（角色）众多，但是角色之间存在共性，在建模过程中，依据封装和抽象的原则，将角色进行了归并，降低了模型的复杂度。例如，出口商角色可以派生出口公司和工厂两个角色，如图4-10所示。工厂角色是经过国家部门批准授权，可以从事经营生产产品进出口贸易的工业企业。存储角色可以派生出3个角色，分别是码头、集装箱场地、仓库，如图4-11所示。海关角色可以派生出如图4-12所示的4个子类。检验部门角色可以派生出如图4-13所示的两个子类。进口商角色可以派生出如图4-14所示的两个子类。贸易管理部门角色可以派生出如图4-15所示的15个子类。银行角色可以派生出如图4-16所示的两个子类。运输角色可以派生出如图4-17所示的运输代理公司、进口港、外运公司、船代理公司、船大副5个子类。
图4-10 出口商角色
图4-11 存储角色
图4-12 海关角色
图4-13 检验部门角色
图4-14 进口商角色
图4-15 贸易管理部门角色
图4-16 银行角色
图4-17 运输角色
3.确定需求用例
根据角色确定用例，一个用例就是系统向用户提供一个有价值的结果的某项功能。用例捕捉的是功能性需求，所有用例结合起来就构成了用例模型，该模型描述了系统的全部功能。用例模型取代了传统的功能规范说明。一个功能规范说明可以描述为对“需要该系统做什么”这个问题的回答，而用例分析则可以通过在该问题中添加几个字来描述，即“需要该系统‘为每个用户’做什么”，这几个字有着重大意义，它们迫使开发人员从用户的利益角度出发进行考虑，而不仅仅是考虑系统应当具有哪些良好功能。
针对上面的进出口贸易项目的需求以及角色来确定用例，进出口贸易项目可分为两个阶段：合同签订阶段和合同执行阶段。这里，以这个项目的出口贸易链的一些业务为例进行说明。
（1）合同签订阶段
合同签订阶段涉及国家对出口商品监管的要求，出口企业需要申请出口商品配额、办理许可证、选定客户并建立业务关系和洽谈成交等，这里主要分析出口商品的配额申请和洽谈成交过程。图4-18是出口贸易链合同签订阶段的用例图，其中用例是“出口配额申请”和“合同洽谈”，参与者是“出口商”“贸易管理部门”和“进口商”。
（2）合同执行阶段
合同执行阶段主要是合同的履约过程，其过程主要包括国际结算、备货、产地证申请、许可证申请、商检、投保、出口报关、出口核销退税、付款/结汇、理赔及运输。图4-19是出口贸易链合同执行阶段的用例图。
图4-18 出口贸易链合同签订阶段的用例图
图4-19 出口贸易链合同执行阶段的用例图
4.分解细化用例
在具体的需求分析过程中，有大的用例（如业务用例），也有小的用例，这主要是由用例的范围决定的。用例像一个黑盒，它没有包括任何与实现有关的信息，也没有提供任何内部信息，很容易被用户（也包括开发者）所理解（简单的谓词短语）。如果用例表达的信息不足以支持系统的开发，就有必要把用例黑盒打开，审视其内部结构，找出黑盒内部的系统角色和用例。这样不断地打开黑盒，分析黑盒，再打开新的黑盒，直到整个系统可以被清晰地了解为止。
现以出口贸易链合同签订阶段中的“出口配额申请”为例，进一步描述其用例的功能。图4-18中的“出口配额申请”用例对于很多人来说是一个黑盒子，不清楚其具体功能，为了进一步描述其内部功能和相关信息，有必要将这个黑盒子打开。这个黑盒子可以进一步通过“计划分配配额”和“招标配额”这两个用例描述，如图4-20所示。
5.用例描述
针对每个用例，可以采用顺序图、活动图、协作图，以及文字等方式进行更加详细的描述，将用例的角色、目标、场景等信息描述出来。
图4-20 “出口配额申请”用例展开
（1）“计划分配配额”用例描述
图4-20中的“计划分配配额”用例对于很多人来说仍然是一个黑盒子，有必要进一步描述其内部信息。“计划分配配额”描述出口公司向省级的地区经贸委外经贸部门提交“计划分配配额申请”并通过审核领取“计划分配配额书”的活动。图4-21为计划分配配额申请的顺序图，图中“出口公司”作为“出口商”的实例，指生产、销售待出口商品的单位，计划配额的分配一般为指定的公司。图4-22为计划分配配额申请的活动图。
图4-21 计划分配配额申请的顺序图
注：标准的UML语法规定，参与者由“实例：类名”组成，此处我们使用了“子类：类名”作为标记。例如，“出口公司”是参与者“出口商”的子类，标记为“出口公司：出口商”。
图4-22 计划分配配额申请的活动图
注：1.活动图中起点（●）、终点
作为一种特殊的状态，分别表示活动开始和结束。
2.同步条（
）也仅表示此处需进行同步，而不关心这种同步是由谁执行的。同步条实际上是一种“与”的关系。
3.标准的UML语法规定，参与者由“实例：类名”组成，此处我们使用了“子类：类名”作为标记。
（2）“招标配额”用例描述
图4-20中的“招标配额”用例也需要展开描述，以进一步说明其内部信息。“招标配额”用例描述了出口配额申请中贸易管理部门采用公开、公正原则实行配额招标的活动。在招标和投标中，双方当事人之间是买卖关系，投标人只能按照招标人提出的条件和要求向招标人做一次性递价，而且递出的必须是实盘，没有讨价还价的余地，没有交易磋商过程，能否中标主要取决于投标人所提出的投标条件是否优于其他竞争者。图4-23和图4-24分别为招标配额的顺序图和活动图。
图4-23 招标配额的顺序图
图4-24 招标配额的活动图
敏捷需求分析方法涉及7个方法工具，即影响地图、需求池（backlog）、用户故事地图、用户故事编写、INVEST原则和行为驱动开发（Behavior-Driven Development，BDD）。
梳理需求时可以采用影响地图（impact mapping），影响地图可视化了从业务目标到产品功能的映射关系，主要用于需求讨论阶段，如图4-25所示。
影响地图由四层级别构成：①目标是什么；②谁能帮助我们实现这个目标，即用户或者与用户相关的人；③通过什么行为帮助我们实现这个目标；④为了产生这个行为，我们的产品需要什么功能。下面来看看每层级别的具体含义。
· 第一层：目标（why），即要实现的业务目标或要解决客户的核心问题是什么。目标应该具体、清晰和可衡量。目标来解释为什么这些事情是有用的，并不是构建一个产品或者交付的项目范围。目标表述待解决的问题，而不是方案，在目标的定义上避免设计上的限制。
图4-25 影响地图
· 第二层：角色（who），即可以通过影响谁的行为来实现目标或消除实现目标的阻碍。角色通常包含：主要用户，如产品的直接使用者；次要用户，如安装和维护人员；产品关系人，也就是虽然不使用产品但会被产品影响或影响产品的人，如采购的决策者、竞争对手等。
· 第三层：影响（how），即怎样影响角色的行为来达成目标。这里既包含产生促进目标实现的正面行为，也包含消除阻碍目标实现的负面行为。这些影响可能是冲突的或者矛盾的或者互补的，我们不需要都支持这些。图4-25中分级的特性很清楚地展示了谁产生了什么样的影响，是如何影响我们的目标的。
· 第四层：功能（what），即要交付什么产品功能或服务以产生希望的影响。它决定了产品的范围，说明作为一个组织或交付团队，需要做什么来实现这些影响，以达成目标。在这里形成是具体可执行的任务项，将来的用户故事将由此而产生。
影响地图是进行需求挖掘和需求规划的一种有效方法，在互联网行业被普遍采用。
需求梳理之后，可以陆续将需求放入需求池中，即放入product backlog中。product backlog是一个敏捷团队管理开发过程的核心，所有的活动和交付物都围绕product backlog来进行。迭代开发是基于用户故事优先级进行的，因此需要对用户故事进行优先级排序。Product Owner负责制定一个按照重要性级别排序的用户故事列表，最后在迭代规划会议上和开发团队确认。规模较小的用户故事可以直接加入product backlog，规模较大的用户故事要先拆分，再加入product backlog进行迭代。
用户故事地图（user story map）已经成为敏捷需求规划中的流行方法，用户故事地图可以将backlog变成一张二维地图，即将用户想要做的事通过二维可视化的方式表示出来。用户故事地图是创建对产品的共同理解、可视化用户需求以及在故事编写中激发用户故事创意的一种方法。
用户故事地图的第一个维度是在地图上水平展开的一系列用户任务。产品负责人引导参与者讨论为实现项目目标需要采取的步骤或行动。
在地图上添加一个物理或虚拟的便签或索引卡，代表序列中的每个步骤。
由于用户故事地图的水平维度代表了一个顺序，因此可以通过在卡片之间插入“然后”一词来进行阅读。可以将图4-26中的地图理解为“用户执行第一步，然后执行第二步，接着执行第三步”，假如你所在的团队被要求开发一款软件，公司员工可以通过它提交费用报告并获得报销。要提交费用报告，员工首先需要登录系统，这就成为地图上的第一张卡片。接下来，员工要创建一个新的空白费用报告，这就成为地图上的第二张卡片（放在登录卡片的右侧），表示这两件事是按顺序发生的。这可以从图4-27中看出来，同时还能看到员工接下来要输入费用，最后提交费用报告。
图4-26 通过在每张卡片之间插入“然后”来横向阅读卡片
图4-27 提交费用报告的初始故事地图
分析上述内容之后，产品负责人或需求分析师通常会将卡片移动到团队的产品backlog管理软件中，并使用用户故事模板创建用户故事。
用户故事地图是二维的，第二维可以理解为一个模块（任务）下的不同功能需求。
仍以费用报告为例，有的用户可以通过复制旧的费用报告来创建新的费用报告，即不新建空白的费用报告，而是复制一份最近的报告，然后编辑副本。如图4-28所示，可以把“复制现有的费用报告”添加到地图中的“创建空白费用报告”卡片下。
由于同一列中的卡片是一个模块的不同功能或者是不同的可选方案，因此在向下读取一列时，可以通过插入“or”（或者）一词来阅读地图。
现在从我们的地图中读到的信息是这样的：用户登录后，创建一份空白的费用报告或复制一份现有的报告，然后输入支出费用，最后提交费用报告。
包含不同（或者备选）方案的卡片应该按照优先级从高到低的顺序添加到地图中，最重要的在最上面，最不重要的在最下面。在绘制故事地图的过程中确定的优先级并不是严格不变的，产品负责人可以进行调整。但是，在一列备选方案中对大致的优先级进行简短的讨论是非常有用的。
图4-28 除了创建空白费用报告外，用户还可以选择复制现有费用报告
有些故事地图可能会非常宽。遇到这种情况时，在地图上添加一行标题会很有帮助。比如，一个简单的文字处理器允许用户格式化、打印和保存文档，这些操作类别可以作为标题添加到地图中，如图4-29最上面的卡片所示。这样可以实现史诗级别的故事抽象，或者说模块分类。
图4-29 添加了标题卡片，用于指示地图各部分的起始位置
在阅读这些标题卡时，同样可以在每个标题卡之间加上“然后”：用户可以先格式化文档，然后打印文档，最后保存文档。
标题卡本身并不是由团队直接实施的故事，而是史诗（或者称为功能模块）、主题或团队用来表示一组相关故事的任何术语（例如功能模块）。
用户故事地图可以帮助团队发现他们可能忽略的用户活动或功能，所以需要从用户体验的角度浏览故事地图，看看是否有遗漏。
在模拟的过程中，在每个步骤中提出几个问题会很有帮助，例如：
· 用户接下来最有可能想要做什么？
· 用户在这里可能会犯什么错误？
· 用户此时可能会为什么感到困惑？
· 用户可能还需要哪些信息？
如果你的产品有多种类型的用户，请针对每种类型的用户都问一下这些问题。例如当站在用户的角度去看我们关于费用报告的示例故事地图时，可能意识到用户经常需要为一些费用附上收据。因此，需要增加一个新的步骤。
也许团队成员会建议产品需要允许用户通过两种方式来实现这一点。首先，如果系统能够激活设备的摄像头并直接扫描收据就更好了；其次，用户需要能够将现有的PDF或图片附加到收据上。把每种方案都添加在故事地图的“附加收据”卡片下方。
由于故事地图是按优先级顺序垂直排列的，因此产品负责人可以使用故事地图来传达产品路线图，展示一个或多个即将发布的版本中功能的预期顺序。要绘制路线图，请在地图上添加一条水平线，然后将必须包含在本次发布或这个产品版本中的所有内容拖动到该线上方。回到之前使用的费用报告系统，一个可发布的产品必须让用户能够登录并制作新的费用报告，因此这些卡片被放置在图4-30中的横线上方，这些卡片功能形成了最小可行产品（Minimum Viable Product，MVP）版本。
图4-30 可以在故事地图中添加横线来展示发布计划
让我们假设一开始使用一个新的空白报告。团队可以在稍后添加复制现有支出报告的功能，因此该功能被置于第一条横线下方，表示它不在第一个版本中。用户需要附加收据，但在MVP版本中只支持拖放上传现有的图片文件。激活移动设备的摄像头以拍摄收据照片的功能计划在第二版中添加，这张卡片被放在横线的下方。
用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括以下三个要素。
· 角色：谁要使用这个功能。
· 活动：需要完成什么样的功能。
· 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
用户故事是范围的单位，是交付的单位。用户故事向他人传递了有用的（或有价值的）信息。在IT环境中，“他人”通常指的是使用系统的人（尽管有时是另一个利益相关者，想以某种方式限制用户，例如保护系统免受未经授权的访问）。然后开始讲故事，这个故事有大有小。通常用它来表示要交付的范围单位，例如“我们已经在此Sprint 2中交付了故事 X 、 Y 和 Z ”。
1.用户故事的编写模板
用户故事的编写可以采用一个标准的模板进行。通常从用户角度以“作为……我可以……以便于……”格式描述用户故事，迫使交付团队始终专注于用户正在试图达成的目标及其原因。模板如下：
As a<type of user>，
I want<some goal>
so that<some reason>.
用户故事常常写在卡片或者即时贴上，也可以是电子卡片。
2.用户故事的验收标准
验收标准称为AC（Acceptance Criteria），可以作为用户故事完成之后的轻量级验收测试，一般写在故事卡的最后，它可以确保团队理解这个故事的实现价值。该验收标准一般由PO角色编写，最后也需要由PO按照AC验证用户故事的实现，图4-31是针对“银行开户”用户故事的描述和验收标准。
图4-31 “银行开户”用户故事描述和验收标准
验收标准的作用如下。
· 以用户的视角表达业务交互过程。
· 为PO与用户的需求理解上提供场景化、具象化的沟通。
· 有助于用户体验友好性的识别和改进。
· PO与团队需求共识的标准和记录。
· 可视化一个用户故事的粗细粒度。
· 开发与测试对功能实现与质量的共识。
· 需求完成边界的限定。
· 比单纯故事点更为直观的工作估算标准。
· 活文档，用户手册（帮助FA Q）的素材。
· 更公平透明的甲乙方的定价标准。
一个好的用户故事应该符合INVEST原则，即独立（不依赖其他故事）、可协商（并非一成不变，可以进行讨论）、有价值（对某些利益相关者，通常是最终用户）、可估算的（足够清晰，交付团队可以清除地知道它有多大）、足够小（小到足以在一个Sprint /迭代中传递多个故事）、可测试（如果无法测试，则显然对任何用户都无济于事）。可以将INVEST属性视为原则，而不是无可争议的规定。一些属性更适用于史诗（Epic）即大故事，而另一些属性更适用于小故事。对于所有故事而言，无论故事多大，它们都必须提供用户可见的内容。
1.I（Independent），独立的
所谓独立性，说的是各个用户故事之间不存在依赖性。原先我们对独立性的理解是，在实现功能先后上不能有依赖性，即A的实现不依赖于B，这样就可以更好地根据价值来进行优先级排序。但是在实际工作中，我们遇到过这种需求：看起来是独立的，但实际上依赖性很强。
假设有一个Epic，要求我们支持信用卡支付，信用卡包括Visa卡、MasterCard和银联卡。我们根据习惯将该Epic拆分为支持Visa卡、MasterCard和银联卡三个用户故事。此时三个用户故事是否有依赖？
从功能角度来看没有，但估算用户故事大小的时候，就有非常明显的影响。支付底层逻辑是三个用户故事共同依赖的，无论你优先完成哪个需求，你都需要完成底层逻辑。因此就会出现，第一个完成的用户故事（假设为A），一定会比另外两个故事增加了一些底层逻辑实现的功能。但如果先实现用户故事B，那么这部分底层逻辑功能就需要加到B上面去。这种情况下，拆分出来的用户故事是有依赖性的。
因此，依赖性的定义包含以下两个方面。
· 功能实现之间没有依赖性，即以任意顺序实现用户故事都可以，不用刻意考虑技术底层。
· 功能之间不要出现共同依赖的底层逻辑，这会让底层逻辑必然在某个拆分的用户故事中实现，这对用户故事的估算带来一定的麻烦，这也是一定意义上的依赖性。
针对上面的示例，我们将Epic拆分成下面的两个或者三个用户故事，这里以两个为例。
· 优先支持一种支付方式。
· 再支持另外两种支付方式。
通过这种方式，我们将用户故事主体中关于信用卡类型的部分隐藏，不会过早地暴露细节，方便优先级排序与工作量估算，然后借助验收标准来完善用户故事（在正式开发之前完善结束），再进入正式的开发阶段即可。
2.N（Negotiable），可协商的
可协商体现在需求实现程度可协商。以登录功能为例，假设有以下的用户故事。
作为商家，我需要可以登录我的后台。
这里的登录到底是什么意思？是输入用户名和密码、手机验证码还是OpenID？是扫码登录还是其他？在我们写下上面的用户故事的时候并没有确定这些，而是需要PO与研发团队共同协商后得出结论。可能当前只需要实现用户名和密码登录，但是在下一个迭代中，需要支持微信扫码登录。Negotiable仅仅是可协商，并不代表PO一定要接受研发团队的意见，毕竟他才是最终决定用户故事的人。
3.V（Valuable），有价值的
在编写用户故事的时候，只需要严格按照用户故事模板来编写，它必然是有价值的。
4.E（Estimable），可估算的
所谓可估算的，是指编写用户故事的人应该具备该用户故事的行业背景。具备行业知识是写出好的用户故事的基础条件之一。
5.S（Small/Size Appropriate），小的/大小适当的
传统的INVEST中，对S的解释为Small，即认为只有小的用户故事才是好的用户故事，有以下几个原因。
· 小的用户故事可以放入短迭代中完成。
· 小的用户故事更容易被研发人员所理解，以便更好地进行开发。
· 小的用户故事更容易被估算。
6.T（Testable），可测试的
可测试的重要性毋庸置疑，这是用户故事验收标准的重要组成部分之一。可测试至少要包含以下两个要素。
· 客观性。所谓客观性是指，从某个测试结果可以得到唯一的结论，即测试通过或者不通过，不存在不同的人在不同的时间用测试结果可以得到不同的结论的情况。
· 可重复性。可重复性是指这种测试不是一次性的，是可以重复验证与测试的。
行为驱动开发（BDD）是一种敏捷软件开发的技术，它鼓励软件项目中的产品负责人、开发者、QA和非技术人员或干系人之间的协作。BDD最初由Dan North在2003年命名，作为对测试驱动开发的回应，BDD包括验收测试和客户测试驱动等一系列极限编程的实践。BDD介于业务领域和开发领域之间，如图4-32所示。
图4-32 BDD图示
行为驱动开发的核心在于“行为”，当业务需求被划分为不同的业务场景，并以“Given…When…Then”的形式描述出来时，就形成了一种范式化的领域建模规约。编写领域特定语言的过程其实就是不断发现领域概念的过程。
用例场景的描述格式“Given…When…Then…”如下所示。
其中，Given从句描述的是场景的前提条件、初始状态，通常是一种现在完成时态；When从句采取某个动作或者是发生某个事件，一定是动词，通常是一般现在时；Then从句用“应该…（should be…）”来描述一种期望的结果，而不用断言（assert），后者与测试关联更紧密。
业务场景一：检查收件箱。下面给出了三个描述。第一个描述涉及过多实现相关的细节，并不合适；第二个描述过于啰唆；第三个描述清晰、明了且能体现业务价值，比较符合上面的要求。
业务场景二：限制非法用户查看某些受限内容，BDD强调什么（What），而不是怎么（How）。
业务场景三：添加图书到购物车并计算总额。
BDD建立在测试驱动开发基础之上，其重点是通过与利益相关者的讨论取得对预期的软件行为的清醒认识。行为驱动开发人员使用自然语言编写团队成员都可以读懂的实例。这让开发者得以把精力集中在代码应该怎么写而不是技术细节上，也最大限度地减少了代码编写者的技术语言与商业客户、用户、利益相关者、项目管理者等的领域语言之间来回翻译的代价。
行为驱动开发在很大意义上来说是一个PO、开发人员、测试人员共创的行为，同时也是一个自然而然的过程，我们可以使用行为驱动开发的人类语言描述方法来编写用户故事。行为驱动开发作为从代码到需求的桥梁，可以使你的测试更加贴近实际的用户行为，从而找到系统的问题所在。
基于BDD的用户故事，使用近于自然语言的方式描述了软件的行为过程，因此，可以直接作为软件的需求文档。
借助AI技术，未来可以实现业务人员和AIGC的直接对话，生成业务所需的软件，而不需要经过程序员这层“翻译”。借助ChatGPT，可以帮助快速梳理思路，AI可以是业务人员、产品经理、敏捷教练、测试人员。下面是ChatGPT助力业务需求梳理的例子。
另外，通过需求讨论的会议纪要等文件也可以实现需求的智能抽取，为需求梳理提供基础。
可以利用AI技术生成需求的具体描述，下面是ChatGPT助力项目编写用户故事的例子。
下面是ChatGPT助力项目梳理MVP的例子。
下面介绍“医疗信息商务平台”项目的软件需求规约和需求变更流程。
下面给出“医疗信息商务平台”需求规约。
由于本项目采用了敏捷生存期模型，可以应对很多变更，但是大的变更还是需要有很好的变更控制。所有用户的需求变更直接由项目经理签收，并纳入变更管理中，对于没有纳入变更管理的需求，将不进行开发。具体的需求变更流程如图4-33所示。
图4-33 需求变更流程
MSHD项目的需求分析采用了传统的UML用例图和敏捷用户故事的方法，形成了软件需求规约。需求规约包括功能需求和非功能需求。首先确定系统角色以及相应的用例，据此给出用户故事地图和用户故事分解情况，然后依次描述每个用户故事。图4-34是MSHD需求规约文档的目录，这个需求规约是按照迭代过程渐进式完善而成的。
图4-34 MSHD需求规约文档目录
根据用户需求描述展开需求讨论和分析，第一步分析讨论的结果产生产品需求池和用户故事地图，如图4-35和图4-36所示。
图4-35 MSHD需求池
我们将所有的用户故事按优先级进行划分，第一次迭代完成系统的基本功能，主要包括用户登录、基于XML和JSON格式的数据获取、灾情数据编码和基本震情编码以及基本数据管理。第二次迭代完成用户注册、参数设置、灾情动态管理和基于地图的展示等功能。第三次迭代完成用户管理、人工数据获取、数据的统计分析和数据请求管理和发送处理。经过三次迭代后将整个系统的功能全部完成，如图4-36所示。
图4-36 MSHD用户故事地图
1.角色分析
角色或者执行者（actor）是指与系统产生交互的外部用户或者外部系统。本系统的角色主要分为数据操作员、系统管理员。
2.需求用例图
图4-37展示了系统用例图，其中，数据操作员负责个人信息管理、数据输入、数据编码、数据管理、数据输出等功能，系统管理员负责数据请求管理等功能。
系统可以按照优先级逐步编写出用户故事（如表4-1所示），表4-2为项目需求规约中用户注册Story的详细描述。
图4-37 系统用例图
表4-1 用户故事集
（续）
表4-2 用户注册Story的详细描述
本章介绍了需求管理的5个过程以及需求分析的主要方法。需求管理过程包括需求获取、需求分析、需求规约编写、需求验证、需求变更。需求分析综述了传统方法和敏捷方法，介绍了基于数据流和基于UML建模方法的传统需求建模方法，以及影响地图、需求池、用户故事地图、用户故事编写、INVEST原则、MoSCoW优先级原则和行为驱动开发等7个敏捷需求分析的方法工具。另外，还探讨了AI驱动的项目需求管理过程。
一、填空题
1. 需求管理包括__________、__________、__________、__________、__________5个过程。
2. 敏捷项目主要采用__________描述需求。
二、判断题
1. 需求规约说明可以包括系统的运行环境。（ ）
2. 数据流分析方法是一种自下而上逐步求精的分析方法。（ ）
3. 需求分析工作完成的一个基本标志是形成了一份完整的、规范的需求规约。（ ）
4. 需求是指用户对软件的功能和性能的要求，就是用户希望软件能做什么事情、完成什么样的功能、达到什么性能。（ ）
5. Story常常写在卡片上，称为Story cards，部署到墙上，称为Story Wall。（ ）
6. 软件项目系统的响应时间属于功能性需求。（ ）
7. 用户故事地图可以将backlog变成一张二维地图，即将用户想要做的事通过二维可视化的方式表示出来。（ ）
三、选择题
1. 下列不属于软件项目需求管理过程的是（ ）。
A.需求获取
B.需求分析
C.需求规约编写
D.需求更新
2. 用户故事INVEST准则中“S”的含义是（ ）。
A.独立的
B.足够小
C.可估计的
D.可测试的
3. 下列不属于UML需求视图的是（ ）。
A.甘特图
B.用例图
C.状态图
D.顺序图
4. 下列关于用户故事描述不正确的是哪一项？（ ）
A.英文名称：User Story
B.不使用技术语言来描述
C.可以描述敏捷需求
D.一种数据结构
5. （ ）是软件项目的一个突出特点，可以导致软件项目的蔓延。
A.需求变更
B.暂时性
C.阶段性
D.约束性
6. 下列不属于结构化分析技术的是（ ）。
A.数据流图
B.数据字典
C.系统流程图
D.用例图
7. 下列不属于软件需求范畴的是（ ）。
A.软件项目采用什么样的实现技术
B.用户希望软件能做什么样的事情
C.用户希望软件完成什么样的功能
D.用户希望软件达到什么样的性能
8. 敏捷项目需求一般采用下面哪一项进行描述？（ ）
A.用例
B.DFD图
C.用户故事
D.数据字典
四、问答题
1. 下图是SPM项目需求规约文档中的一个用例图，请根据图中的信息判断参与者是什么角色？并写出至少3个用例，如登录、注册等。
2. 采用典型的用户故事模板描述上题中的注册功能。