软件工程：介绍用例驱动的需求获取的过程与方法

介绍用例驱动的需求获取的过程与方法

用了两天时间总结了这一章的知识点，我发现知识点很多，就算我一层一层的归纳最后还是会有点混乱，建议大家多次反复阅读，来保证更好的理解整个用例旭东需求获取的框架，如果帮助到你们麻烦点个赞嗷~~这将是对我是最大的鼓励！！

需求获取的过程模型

1. 定义软件问题

   目标：获得对目标软件要解决的主要业务问题以及其业务背景的初步理解，尽量消除需求工程师与用户之间的交流障碍，明确待开发软件系统的目标、业务价值、范围以及边界

   定义软件问题的过程：（不存在严格的时序关系）

   • 标识客户和用户

   需要考虑两种情况：

   1. 软件系统专门为特定的使用方量身定制

      建议需求工程师索取用户完整组织机构图，从组织的机构来考虑以下几种用户：

      1. 用户机构中的第一负责人或者授权的信息化主管，以及软件系统所处理的业务的相应部门负责人（我理解为管理层，掌握最终话事权的）
      2. 软件系统所处理的业务的相关部门中的业务操作员工（对于软件的直接使用者–我们的用户层）
      3. 软件应用过程中负责系统配置、基本维护和技术支援的用户（运行维护人员）

   2. 软件产品面向目前不能具体确定的用户

      建议考虑到用户和客户：

      1. 为本项目提供资源的负责人

      2. 负责策划、构思本软件产品的人员

      3. 负责推广、销售本软件产品的市场营销人员

         注：

         如果软件产品的最终用户是个体，则需要考虑邀请具有代表性的用户参与需求获取活动，向其征询各类需求并请其参加需求验证

         如果软件产品的最终用户是组织机构，则需考虑邀请有代表性的组织机构中第一种情况的三类用户来参与需求获取和需求验证

   • 理解业务背景

     两个目标：

     1. 获得与用户有效沟通所必备的业务知识，并理解与用户需求相关的业务术语，尽量消除需求工程师与用户之间的交流障碍，从而提高后续的需求和分析活动的效率
     2. 获取与目标软件相关的事实和假设

     达成目标的方法：

     1. 从相关用户处获取有价值的业务文档并对其进行分析研究。（有价值的业务文档是指对需求工程师理解业务背景，业务术语和用户需求有所帮助的文档）
     2. 观察并研究用户目前完成相关业务流程的人工操作流程。在系统工程师的帮助下研究软件与系统中其他部件的协同处理流程
     3. 关注业务领域中待开发的软件系统相似或相关的现有软件，通过实际操作或文档研读了解其功能和使用方法。同时思考以下问题：
        • 现有软件可否在软件项目中直接使用？
        • 如何使用
        • 如