第四章 需求定义实践-心得

1. 1 需求定义任务概述

  需求定义，就是定义项目的业务需求，明确项目的目标和范围。

1.1.1 需求定义的时机

  在项目立项时完成，但实际情况需要后期继续完善。

1.1.2 需求定义的理念与策略

  对于混沌不清的项目目标：可以通过内部寻根（寻找真的发起人，理解他的需求）、外部追溯
  需求定义的理念：问题、机会（解决问题、创造机会）
步骤：目标–>问题–>可选方案–>建议方案

1.2 问题分析五步法

1.2.1 在问题定义上达成共识

  问题定义模板

1. 问题定义
   （装换）将未知问题转换成已知解问题。
   （本源）在确定某问题的解决方案时，一定要思考是否会引发新问题。
   直接修改错误，不要用其他方案来弥补错误。
2. 分析影响人群

1.2.2 理解根本原因，也就是分析问题背后的问题

1. 鱼骨图
2. 帕累托分析

1.2.3 确定相关人员和用户

1. Stakeholder解析（利益相关者分析）
2. 用户分析

1.2.4 定义解决方案的界限

1. 理解范围和边界
   范围是涉及的事、物，边界是人与系统的职责边界
2. 确定边界
3. 边界谈判
   用户永远会希望花同样的钱，获得尽可能多的功能
4. 创新边界

1.2.5 确定加在解决方案上的约束

1.3 需求定义的产物与要素

1.3.1 需求定义的产物

1. POS类（Project Overview Specify项目综述）
   
   
2. Vision类（愿景）
   

1.3.2 需求定义的要素

1. 目标
   遵循SMART原则：
     （1）具体的（Specific）：目标必须能够指导具体的工作；
     （2）可度量的（Measurable）：这样才能进行成本效益分析；
     （3）可达到的（Attainable）：否则是没有意义的目标；
     （4）和其他目标具有相关性（Relevant）；
     （5）有明确的截止期限（Time-based）
   目标示例：
   
2. 范围
   见1.4
3. 相关方
   对相关方能力进行建模，只有了解用户的能力特点，才能够提高软件的可用性，因为可用性是相当而言的。

你可以不做一件事，但一定不能不知道为什么需要做这件事。

4. 相关事实与假定
     相关事实：可能对产品影响的外部因素，要罗列出对产品产生影响的其他因素、系统和活动，以便提醒开发者可能对需求产生影响的一些情况和事实。
     假定的内容包括需求定义阶段中所做的假设清单，这些假设都是对产品开发有影响的；它和相关事实的区别在于，它不一定是真爽的，它可能是对用户能力、外部系统性能的一种假设，因此开发人员需要对这些假定进行核实，以免产生无用功的情况。

1.4 定义需求范围

  采用业务导向的层次结构，通过三个相互独立的步骤逐渐演化出需求的范围定义，并且采用两图一纲（构件图、上下文关系图和需求大纲）来描述，为软件需求规范说明书提供最初的目录结构。

1.4.1 划分主题域

1. 什么是主题域
   根据业务流程来分解
2. 使用构件图

各个主题域之间的服务接口是需求变更的防火墙。

1.4.2 确定主题域范围

1. 上下文关系图绘制要点
   首先用一个矩形表示系统，写上系统的名称，将整个系统看作一个黑盒子；
   然后找到该系统的所有Customer（客户），考虑这些Customer会发起什么事件，这些事件会引发Worker（内部工作人员）的什么工作，将这些序列逐一表示出来；
   最后再看看系统的每个Worker还有没有一些发起的事件。
   

1.4.3 标识业务事件与报表

业务事件解析
  业务事件是业务流程的触发点，标识出业务事件能够帮助我们识别出业务流程
  业务流程是为了响应业务事件而触发的一系列业务活动，它通常是由不同部门、不同岗位协作完成的。业务流程的信息掌握在中层管理人员手里，它属于脉络信息。
  业务活动属于一个特定的业务流程，它是一个人的活动，因此一个业务流程应该是由一个或多个业务活动组成的，业务活动和业务步骤的信息掌握在操作层人员手里，它属于细节信息。

（1）业务事件类型

（2）业务事件标识要点
  寻找主动触发的源头。

1.4.4生成需求大纲