《软件需求最佳实践》——阅读笔记一

首先对SERU模型的四个字母再做一个说明         

S:Subject Area，表示子问题域，其核心思想是要通过业务来分解系统，尽量保证业务独立和低耦合。    

E:Event，表示业务事件，通过业务事件能够找到流程，通过流程能够找到不同场景和用例。    

R:Report，表示报表，统一处理查询，分析和统计类需求。     

U:Use Case，表示用例，需求组织的最小单位，到了需求分析阶段的重要活动和产出。

这本书首先从软件需求实践中出现的主要问题和困难入手，指出了改进的主要方向；然后逐一说明了需求定义、需求捕获、需求分析与建模、编写规约、需求验证等需求开发活动的任务、要点和手段；并提出了一个可操作性强、易上手的SERU过程框架，能够帮助读者清楚地了解整个过程，理解各阶段的关键产物和产物之间的关系。

还对包括需求基线、变更管理、需求跟踪在内的需求管理活动的操作要点进行了阐述，给出了具有很强实践性的具体建议。

SERU过程框架模型将需求过程分解为三个阶段，第一个阶段是需求定义，重点是主题域划分和业务事件识别。第二个阶段是沥青需求框架和脉络，重点是通过业务流程图转到具体的领域类图和用例图。到了第三个接团重点就是填充需求细节，包括用例的详细编写，届满和交互设计等。

CHAOS Report调查结果显示：软件项目成功因素的前三名：用户的参与；执行层的支持和清晰的需求描述。失败的前三名是：不完整的需求，缺乏用户参与和资源不足。

采用数据说话是技术人员走向成熟的一个要点。

想让用户代表能够更好地参与到完整性评价中来，就必须采用“业务导向”的组织结构，而是不让用户将一大堆技术动作翻译到自己的业务场景中去。

需求验证本是需求质量关，其目标是暴露更多的错误，也就是说我们要的不是签字，而是指出潜在的问题与错误！

需求规格说明书应该采用业务导向的属性层次结构来组织。树形层次结构应该面向不同的层面：决策者（高层），事务管理层（中层），操作层（基层）将需求分成不同的部分，让合适的人验证适当的部分，然后再汇总。

对于需求分析员而言，真正的专业主义是基于业务利益（解决问题，创造机会，提高管控力等）的沟通。

不切实际的用户期望的原因在于软件的无形和成本的不透明。

到底谁才是知道用户最需要什么功能的人呢？产品经理，开发人员还是用户代表？其实最了解用户需求的是软件本身。看访问量！

优先级的划分经常是拍脑袋的产物。

解决沟通失真的方案：1 文档；2 Re-view. (缓解沟通失真的最有效的方法是及时复述.)

项目经理的需求控制：有些需求“表面上”是控制下去了，但却在后面以“需求变更”的形式全回来了。

需求分析的本质在于业务分析，而非技术分析。方法：多问why.

有种低效的管理叫“打地鼠”，有种低质的医术叫“头痛医头，脚痛医脚”，有种低级的观点是“软件项目失败的关键在于项目管理技能不足。”

以“定性”的方法来描述非功能需求，实际上就是一种无效信息传递。

第一部分-原理模型与误区      

需求定义阶段强调了一个重点就是高屋建瓴和从顶向下的思路。当要做一个全新的软件产品的时候，我们首先肯定是进行需求收集和调研，所以书里面专门谈到了需求捕获的最佳实践，包括用户的访谈和调查，现场的观摩等。同时也提出了类似任务卡片等很好的现场需求捕获工具。为什么一开始要强调第一阶段对系统的宏观把握和高屋建瓴，因为在做一个全新的软件产品的时候我们很容易收集到大量用户现有的流程，表单，组织架构等信息和资料，但是这样很容易一次的陷入到需求细节中而对企业的业务没有一个宏观的把握。         主题域划分+上下文图，是需求定义阶段的重要输出。主题域划分主要是从业务的视角来考虑子系统应该如何划以降低业务本身的耦合，在书中也专门提到了主题域划分的思考应该从组织结构为线索，从分管领导找突破以及借鉴典型的业务职能区块等。主题域划分清楚了下一步重点就是要确定主题域的范围，自然引入了上下文关系图，其核心就是要将主题域或子系统作为一个黑盒来分析，搞清楚边界和其于外部用户的交互。通过理清楚上下文关系图后第一阶段的输出基本就很容易明确了，即业务事件+报表需求。         在这里我觉得重点要借鉴的就是从顶向下的系统思维和分而治之，这是解决问题很重要方法。同时刚开始一定不要跳过这个阶段而落入需求细节。主题域和业务事件是两个重要概念，而这两个概念核心又是业务场景。