2023学年完整公开课版需求获取（2022版）

物流信息管理系统需求获取需求获取确定系统用例作为一个活动，是统一过程需求理论中的一部分。需求捕获和分析是初始阶段的重要组成部分。开发团队必须使用每个可用的源来发现需求（专家、用户、文档、接口、文献等），对于每个来源，还有可能确定一组系统必须实现的功能。一、需求获取需求获取相当于查找系统需要执行的功能的信息，以及系统运行需要遵循的约束条件。在本课中采用系统用例进行记录。

另外一种不使用用例记录需求的方法是使用一个包含着功能需求列表的文档，同时还会附带一系列的约束条件。使用用例的方法相对于使用功能列表，其优点在于良好的用例具有明确的力度，可以生成高级别需求列表，因此比单一功能列表更容易理解。一、需求获取高级别用例的数量通常要比单独功能列表的数量少。当进行高级别用例详细构建时，单一功能会以用例扩展的形式出现。在Lion在线书店的例子中，需求获取使开发团队能够发现系统必须可以控制以下活动：图书的购买和销售、收取书款、允许退回损坏的图书、生成销售报表、查询库存情况等。这些操作及其他操作构成了系统要实现的功能，因此也可以将此称为功能需求。这些功能最后要合并到一个或多个用例当中。一、需求获取同时，在需求获取的过程中，分析师还要面对业务规则或系统实现功能的约束条件。例如，业务规则要求书店在确认图书已付款后才开始寄送图书。这种规则是一个非功能性的需求，可以作为用例本身的注释或备注进行记录，用于在详细说明用例时进行回看或验证（如图1)。或者用一个经过编号的列表或电子表格进行单独记录，用唯一的编号与用例相关联。图1用例中的非功能性需求二、需求获取不是需求设计分析一个系统就像将自己置身于森林中一样。要探索未知的森林，不能直接对每个植物和动物开始探索。“一叶障目，不见泰山（peoplecannotseetheforestforthetrees)”，然而森林是一个庞大的系统，树木是其需求。只有在探索过程的最后，研究团队才能够说他们获得了最小的那一部分知识。必须先采取整体的规划，之后才能研究细节问题。二、需求获取不是需求设计因此，在初始阶段需要提出一一个整体规划，这样才能了解最重要的内容，然后才能将其分解为细化的问题进行分析，最后设计出解决方案。在细化阶段和构建阶段中的组织迭代，可以理解为将森林分成几个区域，以便在某个时间段内探索某个区域，以这种方式来处理其内在的复杂性。因此，初始阶段的最终目标之一是根据用例将工作进行分解，便于在后续的迭代过程中进行探索。二、需求获取不是需求设计在初始阶段，需求获取的过程必须是快速和泛化的。要正确开展这一工作，就必须去发现需求的扩展，而不是其细节。分析师必须理解系统要做什么，而不是要详细说明如何做。只有在细化迭代时才深入分析需求。

需求获取所需的时间仅用于获取需求，而不是提出需求。在这段时间内，分析团队要与客户、用户和其他利益相关者列出所关注的需求列表，以及目前不需要应对的一些限制条件，在下次迭代中才需要更详细地进行需求分析。必须要明确的是，需求是客户提出的，而不是开发团队设计出来的。有些分析人员会把客户提出的需求和系统设计之初的需求相混淆，这种混淆的一种表现形式通常会涉及包含关系型数据库设计的一系列需求。除非现有的系统和新开发的系统要相互兼容，否则将客户的需求用一组关系数据表表现的理由是什么呢？

这可能得要求客户具有相应的计算机学科背景才可以实现了,但这不是常规的规则。数据库表示解决方案领域的一部分，不是问题域。分析师必须能够找到客户的需求及其目标，随后要确定获得的信息是用关系型数据库还是其他的结