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

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

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

需求获取的过程模型

1. 定义软件问题

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

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

   • 标识客户和用户

   需要考虑两种情况：

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

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

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

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

      建议考虑到用户和客户：

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

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

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

         注：

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

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

   • 理解业务背景

     两个目标：

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

     达成目标的方法：

     1. 从相关用户处获取有价值的业务文档并对其进行分析研究。（有价值的业务文档是指对需求工程师理解业务背景，业务术语和用户需求有所帮助的文档）
     2. 观察并研究用户目前完成相关业务流程的人工操作流程。在系统工程师的帮助下研究软件与系统中其他部件的协同处理流程
     3. 关注业务领域中待开发的软件系统相似或相关的现有软件，通过实际操作或文档研读了解其功能和使用方法。同时思考以下问题：
        • 现有软件可否在软件项目中直接使用？
        • 如何使用
        • 如何在当前软件项目的需求工程和软件设计阶段借鉴该软件？
     4. 建议需求工程师在试试以上步骤的过程中，采用UML类图表示业务术语以及其关系，采用UML互动图表示业务处理流程
     5. 在研究业务背景以及与用户交互的过程中，关注并文档化那些对目标软件的定位和开发可能产生影响的各种外部因素，包括假设和既成事实。

   • 策划并实施需求调查

     在需求获取早期，一般围绕这三个目标展开需求调查：

     1. 澄清需求工程师在理解软件问题以及业务背景过程中遇到的疑难问题
     2. 请求用户确认需求工程师对软件问题和业务知识的理解
     3. 确定软件系统的初步定义，包括目标、业务价值、范围、边界

     提出以下问题，并结合需求工程师对业务背景的理解有助于达成这些需求调查目标：

     • 软件系统应解决何种业务问题？

     • 在软件系统设计的业务一领域中，有哪些改进能够为用户提高效益或创造价值？

     • 系统软件能够为这些改进做出何种贡献？

       -----这些问题的答案部分对应于软件系统的目标-------------------------------------------------

     • 目前与上述问题香瓜你的业务是如何运作的？

     • 引入软件系统后，这些业务的运作应该有哪些改进

       ---------这些问题的分析可以进一步明确软件系统的目标和范围-----------------------------

     • 引入软件系统解决上述问题后，可望带来哪些业务方面的创新？

     • 这些创新会带来哪些好处？

     • 能够为用户创造何种价值？

     • 如何度量或者客观的评价这种价值？

       -------------这些问题的答案对应软件系统的业务价值--------------------------------------------

   • 定义软件系统的轮廓，包括其目标、业务价值、范围以及边界

     1. 确定业务目标和价值

        对软件系统的业务目标的描述必须遵循以下原则：

        • 具体而不抽象，实在而不空洞
        • 具有评判目标是否达成的客观标准
        • 具有可行性。必要时应该在描述目标的同时给出评判标准和可行性论述
        • 具有明确的业务价值

        注：对于业务价值的描述可以针对每项目标逐项进行（有利于嵌套关系的表述每项目标的缘由），也可以汇总描述整个软件系统的业务价值（有利于需求文档的读者从总体上把握软件的业务价值）

     2. 确定范围和边界

        范围：指软件需要在那些业务领域完成哪些功能

        边界：指在软件与用户以及外部系统协作的过程中哪些动作不属于软件负责的范围，而是由用户或者外部系统负责（在我看来就是划清界限，哪些是软件负责，哪些不属于软件负责）

        两者的关系：范围取决于目标和业务价值，软件的范围和边界的划定是相关的，这两者的设定是相辅相成的

2. 创建框架用例

   1. 策划并实施用例调查

      需求的来源：系统需求、前述的软件问题定义、政策法规、行业标准、软件运行环境的约束、用户组织或个人

      主要目标：

      • （弄清楚）为实现待开发软件系统的业务目标和价值，针对每项业务，希望软件系统在那些时间点提供哪些支持功能？
      • （弄清楚）在这些时间点，用户与软甲系统之间需要进行何种交互？
      • （弄清楚）软件系统在业务处理过程中必须遵守哪些业务规则？
      • （弄清楚）针对预想的软件系统的每项功能或者其外部行为，希望他们满足那些质量需求或约束

      注：我理解就是要让需求表达的尽可能客观、全面、正确、完整

   2. 以框架用例记录用例调查的结果

      注意事项：

      • 从用户的视角而非软件开发者的视角，采用用户熟悉的业务术语描述用例的名称、功能或者业务目标。用例目标中描述的是主要执行者使用此用例希望达成的业务目标，但是同时也要考虑本用例其他执行者的需求。
      • 尽可能完整的标识每个用例的所有执行者。执行者的命名不能使用职务头衔，更不能使用个体名称，因为执行者是角色而不是个体
      • 对用例的交互动作序列的描述不必细化，甚至可以展示忽略其交互动作序列，更加无需考虑非典型的应用场景或异常处理
      • 只作用于单个用例的规则和非功能性需求应该在用例描述中说明。作用于多个用例的规则以及对于非功能性需求项应该和全局性规则一起在需求规约束中以专门章节的形式出现
      • 在整理非功能性需求时每项需求必须都是具体的、可客观验证的，否则需要再次和提出者探讨如何具体化以及如何客观验证

   3. 创建用例图

      注：用例图在这一步只关注执行者与用例之间的关系

   4. 整合并评审框架用例

      目的：

      • 检查所有的框架用例联合起来是否足以完整覆盖利益相关方的所有功能性需求（完整覆盖的标准是假设所有用例和非功能性需求全部实现，目标软件系统的业务目标和价值是否得以实现，是否遗漏了位于目标软件系统范围内的功能）
      • 检查是否遗漏重要的非功能性需求

3. 精化用例

   目标：将框架用例精化为严谨、完整的用例，精化用例图

   主要工作：确定每个框架用例的交互动作序列

   精化用例的子活动：

   • 分解和合并用例

     用例粒度：用例对应的功能范围相对于整个软件产品的功能而言的规模比。用例粒度越小，用例数量越多，不存在绝对的用例粒度标准

     判断用例粒度是否适当，是否需要合并分解的判断准则：

     1. 经过分解或者合并后获得的用例必须具有业务意义上的相对独立和完整性。只有针对多个用例中公共的交互动作子序列而设置的被包含的子用例可以例外
     2. 用例的分解应该遵循业务层面上的强内聚、松耦合原则，应使得用户和软件开发人员能够更容易的理解被分解的用例以及分解后得到的子用例，而不是相反
     3. 一个软件系统的用例不宜过多
     4. 用例的力度应该确保合理规模的软件开发团队能够在合理的时间周期内实现该用例
     5. 仅仅针对粒度过大的用例才进行用例分解，并且对用例分解不能破坏现有用例在功能需求方面的覆盖完全性

     合并粒度较小的用例的原则：

     1. 合并业务上关系比较密切的多个用例
     2. 在同一业务范围内，合并功能上相似的用例

   • 构建完整的用例

     工作内容：

     1. 重新研究用例名称、用例目标或者功能的表述，标识所有的执行者。用例名称应该采用业务术语，并且反映执行者的主要业务目标。如果多个执行者，单衣在用例名称中涵盖所有执行者的业务目标，则应该以主要执行者的主要业务目标为准

     2. 标识触发和前置条件。（出现的三个前提：具有业务意义、系统可检测、并且不是不言自明的）

        注：应该采用业务术语来描述触发和前置条件

        关联：当触发动作或者事件发生时，并且前置条件成立时，用例开始运作；

        差异：触发条件是用例启动的推动力，前置条件是决定是否阻截此推动力的过滤器

     3. 描述或精化原有的基本交互动作序列

        提炼基本交互动作序列的方面：

        • 观察现有业务处理过程，思考引进新的软件系统后如何优化该过程
        • 通过访谈，深入了解利益相关方希望软件系统在帮助用户完成业务目标的过程中发挥何种作用、完成何种功能。
        • 研究软件系统如何更好地帮助用户
        • 研究执行者和软件系统在协同工作的过程中各自应该在何种时机向对方提供何种交互信息

     4. 提炼并描述扩展的交互动作序列

     5. 描述用户与软件系统交互过程中传递的信息项的主要内容

     6. 标识后置条件

   • 精化用例图

     包含与扩展关系的区分规则：

     1. 如果用例A知道再喝步骤，如何启动用例B，那么A包含B
     2. 如果在用例A执行期间发生了某种事件，用例A不知道，但用例B知道A在哪个步骤，如何启动B中某个动作子序列；并且在没有此类事件发生时，A和B的动作序列相同，那么B应该扩展A

   • 精化业务规则以及非功能性需求

   用例交互动作序列的描述方法：

   1. 基本交互动作序列的描述方法（在不考虑任何例外的情况下，最简单、最直接的交互动作序列）

      描述符昂发

      规则：

      1. 采用带结构化序号的自然语言描述动作序列

      2. 采用主动语态、简单句式描述每个动作，用词力求简洁、清晰。采用参与者动作、系统动作交替的描述交互动作序列。在整个项目范围内保持描述的风格一致性。

      3. 同一使用“系统”指待开发的软件产品，执行者的名称应与用例描述的执行者列表中的执行者名称相一致。

      4. 采用业务而非技术术语描述每个动作，阐明执行者的意图，绝不涉及任何用户界面操作

      5. 从用户视角描述系统行为的外部可见效果，尽量避免描述系统内部的动作。

      6. 用适当的粒度描述每个动作（一般而言，一个用例的最外层动作不应该超过10个。若连续的多个动作由一个执行者向系统传递，那么应该将它们合并）

      7. 避免嵌套使用“如果…那么…”

      8. 在一连串动作的前部或者后部循环，特殊的时序约束或其他有关此子动作序列的其他说明

      9. 适当使用带下划线的名称

         （注：如果用例A包含子用例B，那么当A的动作序列中需要引用B的交互动作序列时，应该采用带有下划线的方法来引用；若一个子动作序列在A中多次被使用，或者单独描述该子动作序列有助于用例动作序列的结构清晰性，可以用带下划线的名称来避免重复）

   2. 扩展交互动作序列的描述方法（在基本交互动作序列的基础上，应为特殊情形的出现而导致动作序列出现分支）

      描述方法 ：

      1. ​ 首先标识可能出现的特别清醒的基本交互动作序列的动作的编号，然后说明扩展分支的条件以及在此条件下的处理动作序列，最后描述扩展处理完成后与基本动作序列的汇合点。

      2. 一般用基本动作序列中的动作编号加英文字母来标引扩展条件，它表示在基本动作序列中相应步骤可能出现条件所示的情形。相应的扩展动作序列则以条件标号再加动作序列来表示。

      3. 为了保持版面清晰，扩展动作序列应该基于扩展条件向右缩进。如果在基本动作序列的同一步骤会出现多个分支条件，则条件标号的字母依字母表顺序向后延伸，但这种延伸并不隐含时序关系方面的意义。

      4. 如果在基本动作序列中的多个步骤会从出现同一分支条件，且相应的扩展处理动作序列也基本相同，则用动作编号序列加字母作为条件标号

      5. 如果在扩展动作序列中再出现分支条件，那么可综合采用上述条件标号规则、扩展动作序列编号规则和版面编排规则，直接在一个扩展动作序列中嵌套的表示另一个子扩展条件以及动作序列

         注：扩展的嵌套不宜过深，若的确有需要，则建议分离出单独的扩展用例来减少扩展嵌套深度

      6. 高层用例中避免扩展条件”爆炸“的方法：若用例M中包含子用例S，并且S中多种扩展条件导致的异常在M中的处理动作相同，则M中应该将它们归并为单个扩展条件

      出现情况：

      • 存在不同于基本交互动作序列的非典型应用场景
      • 执行者或者外部环境在交互过程汇总给软件系统造成基本交互殴打那个做序列无法处理的异常情况

4. 评审用例模型

   成员：需求工程师、利益相关方的代表、项目软件经理、业务专家

   工作成果：软件系统的轮廓、领域概念模型、精化后的用例模型、业务规则、非功能性需求等

   评审的主要关注点：需求的正确性、完全性、可行性

   **注：**用例模型是被评审的主体对象，必须检查用例描述的质量（如：用例是否有助于实现软件系统的目标；用例的动作序列中是否存在软件系统中可以自动实现，但在用例描述中仍是要求用户人工完成的功能等等…）