《掌握需求分析》第二章 需求过程

项目启动

       启动会议的主要目的是为接下来需求发现工作奠定基础，并确保项目成功需要的所有东西都已经到位

       确定业务问题的范围---》确定利益相关者----》确定项目的目标---》成本初步评估（早一些理解风险与成本）---》小组成员是否值得进行和是否可行达成一致意见

网罗需求

      启动会议结束后，需求分析师开始在工作中网罗，学习和理解它的功能性，即“这部分业务是做什么的”。为了获得方便性和一致性，他们将工作上下图划分为一些业务用例。

      每个业务用例都是一部分功能，这是工作正确响应一个业务事件所必需的。每个业务事件都指派一名需求分析师，分析师采用一些技巧，如做学徒、场景分析或用例研讨会等来发现工作的真正本质。

     在理解了工作实质后，分析师和关键利益相关者一起工作，决定改进工作的最佳产品。也就是说，确定多少工作需要自动化或改变，以及这些决定会对工作产生什么影响。当分析师知道了产品的范围，就为它编写需求。

总结：启动会议确定了待改进的工作范围。业务用例可以通过这个范围导出。每个业务用例都由需求分析师和相关利益相关者进行研究，以发现期望的工作方式。在理解了这些之后，就可以以确定适合的产品（PUC场景），并写下需求或用户故事。

快而不完美的建模

     白板上随手画出的原型，对可能实现的需求提供 了快速的视觉解释，并澄清一些误解或遗漏的需求

编写需求

    系统开发的一个主要问题就是需求被误解。为了避免误解，分析师必须以一种无二义的，可测试的方式写下需求，同时确保提出需求的利益相关者理解并同意写下需求，然后再传递给开发者。

    需求规格说明模板/需求项框架

    想编写需求，主要不是为了得到书面的需求（虽然这常常是需求的），而是去“写”需求。写需求这个活动，以及与之相关的理由和验收标准，澄清了编写者对需求的看法，用无二义的，可验证的方式确定下来。换句话说，如果分析师不能正确地编写需求，他就没有理解需求。

质量关

    在每项需求传递给开发者之前，质量关测试每项需求的完整性、正确性、可度量性、无二义性和其他的一些属性，确保它是严格的。

复用需求

复查需求

       复查工作确保规格说明书是完整的，恰当的，这样可以转向下一个阶段。

       复查也为重新评估产品的费用和风险提供了一个机会。既然拥有了一个完整的需求集，对产品的了解就比启动会议要更多。

迭代和增量过程

需求反思

      我们做对了什么？

      我们做错了什么？

      如果我们必须重新做一次，在哪些地方会做得不同？

需求演进

    需求随着产品开发过程而演进。它们开始是相当模糊的想法，分析师和利益相关者会探索工作领域。随着时间的推移，关于产品的想法出现了，需求就变得精确、可测试。它们一直是与技术无关的，直到设计者加入进来，增加了一些技术需求，使产品能够在它的技术环境中工作。

模板

    项目驱动

           项目的目标

           客户、顾客和其他的利益相关者

           产品的用户

    项目限制条件

           需求限制条件

           命名标准和定义

           相关事实和假定

    功能需求

           工作的范围

           产品的范围

           功能与数据需求

    非功能需求

           观感需求

           易用性和人性化需求

           执行需求

           操作和环境需求

           可维护性和支持需求

           安全性需求

           文化与政策需求

           法律需求

    项目问题

           开放式问题

           立即可用的解决方案

           新问题

           任务

           迁移到新产品

           风险

           费用

           用户文档

          后续版本需求

          解决方案的想法

白雪卡

        需求项框架或白雪卡，有需求的各种属性，用于最初的需求收集工作。每个属性都对需求的理解和可测试性有一定贡献。