聆听客户的需求
需求获取是需求工程的核心环节，它旨在确定和理解不同用户群体的具体需要与限制。在软件需求的三层结构中，获取用户需求居于中间层级，上层由项目视图和范围文档中的业务需求 1指导，下层则生成特定的软件功能需求以支持用户完成他们的任务。
通过运用“使用实例”等方法聚焦于用户如何利用系统执行其实际工作，需求获取为从问题识别到解决方案构建架设了桥梁。有效的需求获取过程要求参与者对项目中的客户需求有普遍的理解，以便分析者、开发者和客户共同探索满足这些需求的各种可能方案。关注用户任务而非仅关注用户接口，有助于避免开发团队因过早进入设计阶段而产生的错误。
需求获取、分析、编写需求规格说明以及验证并非线性顺序进行，而是相互交织、增量迭代的过程。在这个过程中，开发团队会不断向客户提问并收集信息（需求获取），同时处理这些信息以理解其内在含义，并将它们分类关联至潜在的软件需求。随后，将这些信息结构化，形成文档和图表供客户代表审查并修正其中的错误。
虽然针对不同的软件开发项目和组织文化，不存在一种统一、固定的需求开发 2流程，但以下列出的14个步骤可作为指导你进行需求开发活动的参考框架：
- 明确项目的愿景、目标和范围
- 确定并划分用户类别
- 在各个用户类别中选取合适的代表参与需求讨论
- 确认需求决策者及其决策机制
- 选择适用的需求获取方法和技术
- 利用这些技术创建使用实例，并为每个实例设定优先级 3
- 收集关于质量属性和其他非功能性需求 4的信息
- 将使用实例详细化，转化为具体的功能需求
- 审查使用实例描述和功能需求文档 5
- 如有必要，构建分析模型以澄清各方对需求的理解
- 开发并评估初步的用户界面原型以启发更多尚未明确的需求
- 根据使用实例创建概念性的测试用例
- 使用测试用例验证使用实例、功能需求、分析模型和原型的一致性和完整性
- 在继续进行各部分的设计和实现之前，循环执行步骤6至13，确保需求经过多轮迭代后达到一致和准确
这种迭代的过程旨在不断深化对需求的认识，减少误解和遗漏，从而提高最终产品的质量和用户满意度。
当完成上述步骤特别是第13步后，就可以有信心地继续进行系统的各个部分的设计和构建，因为你已经为创建一个高质量的产品奠定了坚实的需求基础。
1 需求获取的指导方针
需求获取在软件开发中扮演着至关重要的角色 6，它是识别项目成功与否的关键环节，同时也是最具挑战性、最容易出错且最需要有效沟通的部分。为了确保需求获取的成功，开发团队必须与客户建立紧密的合作关系，并创造一个开放的环境来深入探讨与产品相关的问题。
分析者需明确区分不同的利益相关者 7小组，避免假定所有参与者都对需求有相同的理解。采用合适的技术手段全面考察问题，不仅要关注功能需求，也要充分讨论非功能需求，如性能、可用性、安全性等。同时，要确保用户明白讨论的功能并不意味着一定会被纳入最终的产品设计，对于收集到的所有需求，应进行优先级排序以防止项目范围失控。
在实际操作中，分析者的工作不只是简单地记录客户所提出的需求，而是通过提问和深入了解，揭示用户真正想要解决的问题和期望达成的目标。例如，询问如何扩展业务流程、新系统如何适应未来变化，以及在异常情况下用户有何需求等。这些问题应以开放式问句引导，以便发现潜在需求和细节。
在需求获取过程中，一个重要的任务是揭示和阐明客户所持有的潜在假设，特别是那些可能导致冲突的部分。分析者需要深入理解客户的意图，找出他们可能没有明确表达但希望包含在产品中的特性或功能。Gause 和 Weinberg提出的“上下文无关问题”是一种有效的策略，这类高层次的问题能帮助我们全面了解业务问题及其可能的解决方案。例如，询问产品的精度要求或是让客户解释为何不同意某个观点，这样的开放式问题能够更直接地揭示深层次的需求，而封闭式问题往往无法做到这一点。
需求获取应当充分利用所有与问题域相关的信息来源以及软件解决方案中合理的特性描述。研究显示，相较于失败的项目，成功的项目通常在开发者和客户之间采取了更多元化的沟通方式。对于业务软件包或信息管理系统的应用来说，与单个客户或潜在用户群体进行座谈讨论是一种传统的、行之有效的需求收集方法。直接聘请实际用户参与需求获取过程，可以为项目赢得支持并确保各方对最终成果的认可。
每次座谈会后，记录下讨论的要点，并请参会用户评论和修正，以确保准确无误。尽早且频繁地开展此类讨论是成功获取需求的关键步骤，因为只有提出需求的人才能确定需求是否已被正确理解和捕捉。应深入挖掘和分析，消除任何存在的冲突或不一致性。
在理解用户需求时，要努力揣摩用户表述其需求背后的思维过程，仔细研究用户执行任务时的决策逻辑，并提取出其中的潜在关系。流程图和决策树是可视化这些逻辑路径的有效工具。
同时，在需求获取阶段要注意避免过早陷入具体细节。在达成关于核心客户任务的共识之前，用户可能会过于关注报表设计、对话框布局等细节问题。如果将这些细节过早记录为需求，可能会给后续的设计工作带来不必要的束缚。因此，有必要周期性检查需求获取的过程，确保用户参与者保持在适合当前讨论主题的抽象层次上，并向他们保证开发过程中将会详细地实现他们的需求。
在逐步细化的过程中，多次迭代地描述需求，首先确定用户的总体目标和任务，并转化为使用实例。然后，将任务进一步转换为功能需求，以便用户完成其任务；同时，也定义非功能需求来描述系统的约束条件和用户对系统质量的期望。虽然初步的屏幕设计有助于展现你对需求的理解，但必须对用户界面设计进行更为细致的打磨和完善。
2 基于使用实例的方法
多年来，分析者在获取和描述用户与软件系统交互需求时，经常采用故事化或情境化的方法。Ivar Jacobson等人将这种方法进一步系统化，并引入了使用实例（Use Case）的概念来进行需求获取和建模工作。尽管使用实例最初源于面向对象的开发环境，但因其关注的是用户如何与系统互动以达成目标，而非具体的实现技术细节，因此该方法也被广泛应用于多种开发方法的项目中。
使用实例是一种结构化的表述方式，它详细记录了系统与外部“执行者”为了完成特定任务而进行的一系列交互过程，这些交互最终能为某个利益相关方带来价值。这里的“执行者”可以是人、其他软件应用、硬件设备或其他任何与系统进行交互以实现其目标的实体。在实际应用中，一个执行者角色可能映射到多个潜在的用户类上，例如，在“物流管理系统”中，“确认库位可用性”的使用实例就包含了一个名为“仓库管理员”的执行者角色，这个角色可以由客户或仓库的工作人员等不同人员扮演。
通过使用实例来表达用户需求，能够确保所描述的需求紧密贴合系统的业务需求。分析者与用户必须共同审查每一个使用实例，确认它们是否符合项目定义的范围后，再将其纳入正式需求文档。基于使用实例方法进行需求获取的核心目的，在于全面捕捉并描述用户需要借助系统完成的所有任务。理论上讲，所有合理的系统功能都应体现在使用实例集合之中。虽然实际上不可能做到绝对的全覆盖，但是相较于其他已知的需求获取方法，基于使用实例的方法往往能够更为有效地识别出关键需求和场景，从而更接近于全面覆盖的目标。
2.1 使用实例和用法说明
在软件工程和需求分析中，一个使用实例（Use Case）是描述系统功能如何满足特定参与者（如用户、外部系统等）目标的一系列相关动作和交互的集合。
主过程（普通流/满意之路）：在“查询仓位库存”的使用实例中，主过程指的是从用户发起请求到获取并显示仓位库存信息这一基本步骤序列。当此流程完成时，用户能够了解到当前仓库中的物流管理情况，并据此可能做出进一步决策，例如是否需要订购更多物料。
可选过程：在同一个使用实例或不同的使用实例中，存在一些额外的逻辑路径，这些被称为可选过程。例如，在“查询采薇库存”（这里可能是笔误，应当为“查询仓位库存”）的场景中，“向物流管理仓库查询仓位库存并选择合适的容器”就是一个可选过程，它允许用户根据查询结果对多种容器进行筛选和选择。
公共函数与包含关系：为了减少冗余和提高一致性，多个使用实例间共享的功能可以抽象为独立的使用实例。这种公共使用的部分可以通过UML中的
include关系来表示，意味着其他使用实例在执行过程中必须包含这个公共使用实例。这类似于编程语言中的公共子程序或方法调用。例外处理：在某些情况下，系统可能会遇到无法按照正常顺序完成任务的情况，这些称为例外或异常路径。例如，“查询仓位库存”使用实例的一个例外条件是没有业务上可用的物流库存。正确地定义和记录这些例外路径对于确保系统设计时考虑各种边界条件至关重要，以免因未预见的异常导致系统崩溃或不恰当的响应。
通过合理地组织使用实例、明确普通过程、可选过程及异常处理，开发团队能够更好地理解用户期望的行为模式，从而设计出更贴近实际需求、更具鲁棒性的软件系统。
2.2 确定使用实例并编写使用实例文档
确定使用实例的方法多种多样，可以采用以下方式：
识别执行者及其角色：首先明确系统中的各个执行者（用户、外部系统等）以及他们在业务流程中的作用。通过分析这些角色在业务过程中的活动，可以推导出相应的使用实例。
关联外部事件与执行者：发现可能触发系统响应的外部事件，并将这些事件与相关的执行者及具体的使用实例相结合，形成系统的功能需求。
从日常行为和业务过程提炼：以叙述形式记录业务过程或日常操作行为，从中抽象出使用实例，并确定哪些执行者参与其中。
从现有功能需求中提取：审视现有的功能需求说明，从中提取并转化成使用实例。如果某些需求不符合使用实例的模式，应当考虑它们是否真正必要或者是否需要重新定义。
为了确保使用实例准确反映不同用户类的需求，在物流管理系统项目中，分析人员组织了一系列持续时间为2到3小时的使用实例收集研讨会 8，会议间隔一天举行一次。参会者包括代表特定用户类的产品代表、其他被选出的用户代表，以及至少一名开发者。当用户提出看似不可行的需求时，开发者的早期参与有助于及时评估其可行性，从而更好地理解即将开发的产品特性。由于不同的用户类对于多个使用实例的需求不尽相同，“物流管理系统”项目的研讨会有针对性地邀请了不同用户类成员参加。
在研讨会上，分析人员会让用户先思考他们期望新系统能够完成的任务或业务流程。每个任务都可以作为一个候选使用实例，分析人员会为这些实例编号并命名，如“查询仓位库存”或“打印物流管理安全数据单”。小组讨论过程中，有时会发现一些实例实际上可以合并为一个更抽象的使用实例，同时也会剔除超出项目范围 9的建议实例。此外，团队还可能在讨论过程中发现先前未考虑到的额外使用实例。
在确定优先级方面，通常的做法是根据用户最初关注的重要程度来排序使用实例。另一种方法是在提出候选使用实例时，为其编写简短的描述，然后根据描述内容来决定优先级。优先级高的使用实例会被首先详细填充内容，随后再重新评估其余使用实例的优先级。
每次需求获取研讨会后，都会探索并记录多个使用实例，并按照标准化模板将其整理成文档，以便后续的设计与开发工作。
在收集和分析使用实例的过程中，参与者遵循一系列步骤来确保需求的准确性和完整性：
- 识别操作者与受益人：首先确定哪些用户或角色将是执行使用实例并直接从中获益的主要操作者。
- 定义先决条件与后续条件：明确为了满足该使用实例而必须存在的前提条件，以及在成功完成使用实例后系统应当达到的状态或触发的事件。
- 估计使用频度：通过预估使用实例的使用频率，可以为系统的并发处理能力和性能要求提供初步指导。
- 交互设计探索：询问参与者希望如何与系统进行交互以完成任务，并记录下操作者动作及预期的系统响应顺序。这形成了一个流程流，可以用对话形式表示，也可以通过图形工具如流程图更直观地展示出来。
- 记录对话与注释：在每个使用实例文档中详细记录每一个执行者动作及其对应的系统响应，以便于后续的设计和开发工作。
- 模板化与可视化表达：创建使用实例模板并在讨论过程中逐步完善内容，对于包含复杂逻辑或决策路径的情况，采用流程图等图形表达方式有助于理清思路。
- 处理例外情况：对可能出现的异常场景和特殊情况（例如数据库离线、物流管理不可用等）进行深入探讨，并将这些例外情况纳入使用实例文档。
- 渐进式挖掘与细化：避免一次性挖掘所有使用实例，而是采取分阶段的方法，每研究清楚一个使用实例就转移到下一个。同时，在整个过程中不断评价、提炼和完善已获取的需求细节和潜在的用户接口设计。
- 从使用实例到功能需求：研习会结束后，分析者根据使用实例说明提取出具体的功能需求，其中一些是明显的，比如特定的数据标识规则；另一些则需要进一步转化为开发者需要实现的具体功能。
- 撰写结构化需求文档：分析者将以分级结构化的形式编写功能需求文档，这种格式便于整合入软件需求规格说明（SRS），为后续的系统设计和开发提供清晰、详尽的指导依据。
在需求分析过程中，对于复杂的使用实例，采用图形化分析模型是十分有效的辅助手段。这些模型包括但不限于：
- 数据流 10程图（DFD）：用来描绘数据如何在整个系统中流动以及各处理步骤间的数据转换关系。
- 实体关系图（ERD）：用于描述系统的不同实体及其之间的关系，特别是在数据库设计阶段。
- 状态转换图（STD）或状态机图：展示对象或系统在不同条件下的状态变化和转移过程。
- 对象类与联系图（UML 类图等）：表示软件系统中的类结构、继承关系以及关联关系。
- 用户接口机制的对话映像：模拟用户与系统之间交互的过程，帮助理解用户操作和系统反馈的逻辑。
通过构建和审查这些模型，分析者可以从多个角度深入挖掘和清晰表达需求，从而揭示文档中可能存在的遗漏、模糊不清和不一致之处。每天研习会后，参与者都会对功能需求进行复查，这有助于及时发现并修正可选过程、例外情况、错误的功能需求及执行者—系统对话中的遗漏步骤。然而，为了保证参与者的有效审查，不宜过于频繁地组织研习会，一周内主持2至3次较为合适，以确保参与者有足够的时间消化和反思所讨论的内容。
此外，在需求开发阶段早期，测试人员可以根据使用实例为“物流管理系统”设计概念性测试用例。这些测试用例不仅能够帮助开发团队明确文档编写，并达成对系统预期行为的共识，还能够验证分析者是否已从测试用例中捕获到所有必需的功能需求。同时，它们也是检验分析方法正确性和一致性的重要工具。
虽然大型系统可能涉及大量的使用实例，需要投入大量时间来识别、详细说明、记录和审核，但通过举办使用实例研习会明确系统预期功能的做法，是对构建高质量、能满足多样化用户需求的软件系统的宝贵投资。
2.3 使用实例和功能需求
使用实例（Use Cases）是描述用户如何与系统交互以实现特定目标的高层次描述，它们通常不提供开发者在编码阶段所需的详细功能规格。为了减少开发过程中的不确定性，并确保软件设计和构建的准确性，将每个使用实例细化为具体的功能需求至关重要。
以下是三种结合或单独利用使用实例来编写功能需求文档的方法：
- 仅利用使用实例的方法： 在这种方法中，功能需求直接嵌入到每个使用实例的说明文档中。当多个使用实例共享相同的功能时，可以通过交叉引用或引入“包括”关系，即将公共功能抽象成一个独立、可重用的使用实例，避免重复描述。不过，对于与特定使用实例无关的全局性需求，可能仍需单独维护一份软件需求规格说明。
- 利用使用实例和软件需求规格（Software Requirements Specification, SRS）相结合的方法： 此方法下，使用实例用于表述用户的高级需求和场景，而从这些使用实例导出的具体功能需求则被记录在SRS文档中。通过建立使用实例与功能需求之间的跟踪关联，可以明确二者之间的映射关系。采用数据库或业务需求管理工具进行存储和管理，便于追踪和更新这些联系。
- 仅利用软件需求规格说明的方法： 这种情况下，虽然使用实例作为组织和理解需求的一种结构化框架，但它们并不需要单独写成详细的文档。所有功能需求都在SRS文档中统一记录和定义，且无论一个功能需求是否由多个使用实例共用，都只在一处详述，并在其他相关处通过参考原始说明的方式来避免信息冗余。这样确保了需求的一致性和易于管理。
2.4 使用实例的益处
使用实例方法在软件需求工程中的优势主要体现在以下几个方面：
- 以用户为中心：通过模拟用户与系统的交互过程，使用实例方法关注于用户的实际任务和目标，这有助于确保系统设计围绕着用户的核心业务流程进行。这种方法能让非技术人员（如最终用户或利益相关者）更好地理解新系统将如何支持他们的日常工作。
- 清晰的任务描述：每一个使用实例都详细描述了执行者（用户或其他外部实体）如何通过一系列步骤与系统互动来完成一个特定的目标任务，这样在需求获取阶段就能更准确地捕捉到关键的用户需求，并避免遗漏重要的功能点。
- 早期发现问题：对执行者—系统对话的详尽分析有助于识别潜在的需求模糊性、不一致性和遗漏之处，在项目初期发现并解决这些问题可以显著减少后期开发的风险和成本。
- 防止功能孤立：使用实例强调了功能与用户实际工作流之间的联系，能够预防那些看似有用但实际上与用户任务无关的功能被盲目开发，从而提高了开发资源的利用率。
- 技术层面的指导：从面向对象的设计角度来看，使用实例有助于识别和定义域模型中的关键对象及其职责关系。开发者可以根据使用实例直接映射出对象模型，当业务规则发生变化时，也能更容易地调整相应的对象行为和功能实现。
- 跟踪变化的影响：通过将功能需求与它们所源自的使用实例保持紧密关联，整个软件开发生命周期中的变更管理变得更加可控。当业务过程随着时间推移而演变时，可以清楚地看到这些变化如何影响到各个层次的需求、设计、编码和测试活动，从而做出及时有效的响应。
2.5 避免使用实例陷阱
在使用实例方法中，确实需要注意以下几种潜在的陷阱 11以确保需求获取和分析的有效性：
- 使用实例过多与过细：
- 避免编写过于琐碎或重复的使用实例，应该将普遍流程、可选分支以及异常情况整合到一个高级别的使用实例中，而不是为每个小步骤创建单独的实例。
- 确保每个使用实例聚焦于一个独立的任务目标，避免把交互序列中的所有步骤都拆分成多个实例。
- 使用实例冗余：
- 当相同的功能在多个使用实例中反复出现时，应通过“包括”关系来减少冗余。可以将共享的功能抽象成通用子过程，并在需要的地方引用该子过程的使用实例，避免多次重写相同的实现内容。
- 过分关注用户界面设计：
- 使用实例不应当详述用户界面的具体表现形式，而应侧重于描述执行者如何通过系统完成业务逻辑。具体的屏幕展示和交互细节应在后续的设计阶段处理，使用实例主要捕捉概念上的对话流。
- 在使用实例中嵌入数据定义：
- 不建议在使用实例中详细说明数据项、结构及其属性。这样容易分散注意力且可能导致数据定义的冗余和不同步。正确的做法是将数据定义集中存储在项目范围内的数据字典 12中，确保数据的一致性和易查找性。
- 过度依赖使用实例覆盖所有需求：
- 使用实例主要用于描述用户任务相关的功能性需求，但并非所有需求都能直接映射为使用实例。例如，非功能需求（如性能要求、安全规范等）、外部接口需求及一些与特定任务无关的需求可能需要在独立的需求规格文档中进行专门阐述。因此，在需求工程中应结合多种方法和工具全面捕获各类需求。
3 对客户输入进行分类
在需求分析过程中，分析者需要对客户提供的大量、零散且可能不完整的信息进行分类和提炼。以下是对各类信息类型的归纳：
- 业务需求：描述的是项目带来的经济效益或战略 13目标，如市场份额增长、成本节约等。这些需求关注于软件产品如何帮助企业达成其商业目标。
- 使用实例与用例说明：用来描绘用户如何通过系统完成实际业务任务以达到特定目标。与客户合作识别并概括出典型的业务工作流程场景，形成高层次的使用实例。
- 业务规则：规定了在特定条件下执行活动的约束条件和原则，比如角色权限分配、业务流程中的控制点等。业务规则可以指导功能设计，但本身不是功能需求。
- 功能需求：直接描述系统的具体功能行为，例如“用户应能进行某某操作”或“系统应该提供某某服务”。功能需求是软件需求规格说明书的核心部分，必须明确其必要性，并确保避免将过时或无效的业务过程纳入新系统中。
- 质量属性（非功能需求）：涉及系统性能、可用性、易用性、安全性 14等方面的特性要求，如响应时间、用户体验、系统稳定性等。分析者需与客户共同澄清这些主观表述的具体含义。
- 外部接口需求：指明系统与其他系统、硬件设备及数据源之间的交互方式，包括输入输出格式、通信协议等。
- 限制条件：也属于非功能需求范畴，用于设定开发和设计上的边界，如技术选型、资源消耗上限等。分析者需区分必要的限制与可能妨碍创新解决方案的不合理限制。
- 数据定义：当客户描述数据元素的结构、格式、默认值以及允许值范围时，这是在进行数据定义。这些信息应当整理到数据字典中以便项目各方参考。
- 解决方案建议：若客户提出了具体的实现方法或交互设计方案，这通常是解决方案而非需求。分析者应注意不要被客户的解决方案引导，而应集中精力了解背后的实际需求及其背后的业务动机，从而提炼出真正的系统需求。
4 需求获取中的注意事项
在需求获取阶段，准确界定产品范围至关重要。如果范围定义过大，可能导致收集了过多的需求，增加项目复杂性、延长开发周期，并可能引入冗余或不切实际的功能。这不仅会消耗额外资源，还可能模糊产品的核心价值。
相反，若项目范围定义过小，则可能会遗漏关键的客户期望和业务需求，最终交付的产品可能无法满足用户的实际需要，造成用户满意度下降。在这种情况下，适时调整项目范围是必要的，但必须谨慎处理，确保变更不会对项目的整体目标、时间表和成本产生颠覆性影响。
需求获取过程应侧重于明确“做什么”，而不是“怎么做”。尽管设计实现方案对于系统开发同样重要，但在需求分析阶段，关注点应在于理解和记录用户需求的本质，而不涉及具体的技术实现细节。通过创建分析模型、绘制屏幕草图和构建原型等手段，可以帮助各方更好地理解需求，并有效地发现潜在的错误和遗漏。
团队规模也是影响需求获取效率的因素之一。过多的参与者可能导致讨论陷入琐碎细节、意见难以统一的局面，从而拖慢进度。实践中发现，精简参与人员，选择具有代表性的关键角色（如客户、设计师、开发者等）组成高效团队，往往能够加快决策进程并确保关键需求得到充分考虑。
同时，避免仅依赖少数几位声音响亮或者影响力较大的用户来决定所有需求。这样容易忽视其他用户群体的重要需求，导致产品不能全面反映大多数用户的诉求。最佳的做法是识别并邀请到各个用户类别中有代表性和受广泛支持的代言人，确保从多元化的视角出发，全面而公正地获取与整合用户需求。
5 如何知道你何时完成需求的获取
在需求获取过程中，确实不存在一个明确的终点标志，因为需求可能会随着时间和深入探讨而不断演化。然而，以下迹象可能表明你已经接近或完成了需求收集阶段：
- 使用实例枯竭：当用户无法再提供新的、有意义的使用场景时，这通常意味着核心功能和主要工作流的需求已经被充分讨论。
- 新实例与现有需求重叠：如果用户提出的新使用实例可以通过对已知功能需求稍作调整或扩展来满足，说明当前的需求集合可能已经涵盖了大部分重要的业务流程。
- 重复讨论：当用户开始反复讨论已经记录过的问题或者需求时，这可能是需求探索达到饱和的一个信号。
- 新需求优先级 15较低：新出现的需求相对于已经确定并排好优先级的需求来说，其重要性和紧急性较低，这表明关键需求已基本捕获完成。
- 着眼未来而非当前产品：当用户开始更多地讨论超出项目当前范围的长期展望或未来迭代的功能要求时，可能暗示当前项目的具体需求已经相对清晰。
- 功能清单对比：在项目启动初期定义了一份预期功能列表，在需求开发阶段将其与实际识别出的功能进行比对，若没有显著遗漏或不一致之处，则可能意味着需求收集过程接近结束。
尽管如此，需求管理是一个持续的过程，并且应当保持一定的灵活性以适应变化。即使在上述情况出现后，也应继续关注市场动态、客户反馈和技术更新，以便适时调整产品需求。同时，确保通过评审 16会议、迭代规划等机制来确认和锁定最终的需求集合并达成共识。
6 实践
- 对客户意见进行细致分类：在整理客户提供的所有反馈时，要识别并区分哪些属于功能需求，哪些不属于。对于非功能需求的内容，应将它们适当地归档至软件需求规格说明文档的相应部分，或转移到其他相关文档中。
- 创建使用实例示例：设计一个完整的使用实例，其中包含主过程、可选流程和异常情况。确保为每个步骤定义明确的功能需求，这样用户才能顺利执行这个使用实例。同时，核查现有的软件需求规格说明书是否已包含了完成该使用实例所需的所有功能需求。
- 分析项目中的需求获取方法：列举当前项目中所采用的各种需求获取技术，并评估其有效性。确定哪种方法最有效（例如，通过实际效果、效率和成本等方面考虑），解释原因；指出哪一种方法不可行及理由。基于此，选择你认为最优的需求获取策略，并规划在下次项目中如何更有效地应用它。在此过程中，请牢记在实践过程中遇到的障碍，以及当时是如何巧妙地解决这些问题的，以便于在未来改进和优化需求获取流程。
6.1 示例
假设的客户意见输入：
- 用户应能够通过用户名和密码登录系统。
- 系统需要支持多种语言切换以满足国际用户的需求。
- 我们希望在主页上展示最新活动通知和特价商品。
- 登录后用户的个人资料页面应该可以编辑联系方式和偏好设置。
- 如果用户连续输错密码三次，账户应锁定并发送解锁邮件提示。
分类：
- 功能需求：1, 4
- 非功能需求（或质量属性 17）：2 （多语言支持）
- 用户界面/用户体验需求：3
- 安全性需求：5
对于第5点，尽管它涉及账户锁定和邮件通知，这些也是为了保证系统的安全性和可用性，所以可归类为安全性需求。
使用实例：购买商品
主要过程：
- 用户登录系统。
- 用户浏览商品列表。
- 用户选择商品并添加至购物车。
- 用户进入结算流程填写收货地址和支付信息。
- 用户确认订单并完成支付。
- 系统处理订单并向用户发送订单确认邮件。
可选过程：
- 用户在结账时选择使用优惠券或积分抵扣部分金额。
- 用户在提交订单前修改购物车中的商品数量。
例外情况：
- 商品库存不足时，系统自动从购物车中移除该商品，并提示用户。
- 在支付过程中遇到问题（如网络中断），允许用户重新尝试支付。
功能需求：
- 用户身份验证与授权机制。
- 商品搜索与浏览功能。
- 购物车管理功能。
- 结算流程及订单提交功能。
- 支付接口集成。
- 库存同步更新与通知机制。