画布 1
需求
  需求定义
    任何能驱动设计做出选择的东西
    需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性，可以是一种对系统开发进程的约束。
    需求就是定义系统做什么而不是怎么做。需求不定义解决方案。
    需求最重要的是定义了系统必须做什么和它必须能够完成的行为
    定义需求的过程就是确定一个系统需要做什么的过程。每一个曾经被开发过的系统都定义过需求，不管需求是否被明确地说明。
    应该写下所有对需求的思考，并独立于解决方案的设计，这样需求就可以被讨论并证明它们的正确性
  需求分类
    产品需求
      三个层次
        业务需求
          业务目标
        用户需求
          用户目标或任务
        功能需求
          开发需要实现的功能
      三种交付物
        愿景和范围文档
        用户需求文档
        软件需求规格说明
          SRS
      非功能性需求
        定义
          系统必备的属性或约束
        常见非功能性需求
          质量属性
            非功能性需求的一种
          系统运行环境
          兼容性
          监管
          发行许可
          地域性
      特性
        逻辑相关的功能性需求集合
      业务规则
        作用
          引出功能需求或非功能性需求
        常见业务规则
          公司政策
          政府法规
          工业标准
          计算方法
    项目需求
      项目的其他诉求和产出
  需求工程
    需求开发
      获取
      分析
      规范说明
      验证
    需求管理
      确定需求基线
      评估提议需求变更可能产生的影响
      保持项目计划与需求同步
      根据预估的需求变更心可能带来的影响，商定新的承诺
      定义需求之间存在的关系和依赖
      跟踪每个需求到他们各自对应的设计、源代码和测试
      在整个项目过程中跟踪需求状态和变更活动
  基本原则
    1.定义问题，而不是解决方案
      需求的目的不是企图定义任何的解决方案。这事重要的特点，是不可违反的规则。
    2.定义系统，而不是项目
      需求定义了系统需要做什么，它们是一组目标。项目是在一段时间内动员一组人来完成这些目标。需求不涉及系统如何完成目标，这意味着不要设计实现一个解决方案的项目的任何事情。
      需求规格应该是长期有效的，适用于多个系统，这些系统可能在不同的时间以不同的方式开发。
    3.区分正式和非正式部分。
      非正式部分用于理解需求。
    4.避免重复
      每一项信息只表述一次。重复产生了额外的工作而且加大了不一致的可能性。
  需求流程
    传统需求流程
      准备
      收集信息
      编写需求规格草稿
      评审规格
      评审后修改
    敏捷需求流程
      原则1：区分问题和解决方案是重要的。
        不管什么方式、必须决定系统必须做什么，也必须决定怎样做。首先确定做什么是良好的事件。
      原则2：定义需求后，一定要记录它以便别人可以找到。
    极限需求流程
      极限编程开发新的系统首先要求用户编写完整的用户故事。用户故事是用户希望系统为他们完成的事情的简短描述。
      任何开发任务的第一步应该是问：我正在做什么？我要解决什么问题？开始之前回答这些问题，然后把这些答案写下来作为这个任务的测试定义的开始。并且以一个需求的形式写下来。
    增量需求流程
      当且仅当真正需要的时候才做需求工作。
      1）前期充分地定义需求，使客户相信我们已经理解了他们对系统的期望，获得客户批准后继续进行。
      2）当开发人员准备好开发一个特定的部分时，扩展那部分的高层需求，定义满足高层需求的系统需要的所有详细需求。