软件需求最佳实践读书笔记
1、需求规格说明不应该采用技术为导向，应该采用业务为导向来组织，分别面向不同层面（决策者、事务管理层、操作层）将需求分成不同的部分，让合适的人验证适当的部分，然后再汇总。
2、不要再把review活动叫做评审了。
3、最简单、最有效的review就是在用户代表阐述了需求之后，需求分析用自己的语言再复述一遍，以确保沟通没有失真。（工作安排技巧：让工作接受者复述任务内容）
4、业务场景中才能得到需求实质，业务场景中步骤性工作可能不是连续进行的。
5、采用满意/不满意模型进行需求必要性评价以辅助确定需求的优先级。
6、需要按照业务、技术开发、项目管理三个角度来确定优先级，技术开发、项目管理只提级不降级。业务角度根据业务价值和频度进行评价，技术开发根据技术依赖性进行调整，项目管理根据项目风险对优先级进行调整
7、编写需求规格功能书时，应确保一类信息只在一处描述，特别是数据字段信息。
8、SERU模型：Subject->Event/Report->User Case。按照构建主题域，标识业务事件和报表类型，再进行事、物、人分析标识出用例，再建模。
9、需求定义可按照目标->问题->可选方案->建议方案来进行
10、问题定义过程中寻找本源需要深刻理解《你的灯还亮着吗？》中的隐喻。即需要思考确定解决方案时是否会引发新问题，务必直接修改错误，不要用其他方案来弥补错误。
11、常用的业务流程+管理形式的主题域划分方式是基于“物”的线索的，这样划分在进行需求捕获和分析时就会发现各个子系统和模块与客户部门是交错在一起的，每个模块都需要对不同的部门进行调研，这只是一种逻辑划分，并没有很好体现业务结构。
12、需求捕获过程中不仅仅需要捕获意识到的需求，还要捕获无意识的需求，如果在捕获到未梦想的需求就更好了。
13、需求分析人员需要尝试理解业务场景，并需要处理客户言过其实、越俎代庖、非正事、抗拒、推卸责任等心理，分别采取多人访谈找差异、识别正确访谈者、离开办公室或对访谈进行计划、倾听抱怨、让被访谈者介绍工作场景方法来化解这类心理活动造成的阻碍。
14、客户如果提出解决方案，需要多问一次为什么需要这样，以找到问题的本质。
15、用户访谈中被访谈者建议包括四类：高层管理人员、中层管理人员、操作层、技术团队，分别在需求定义、需求捕获阶段
16、业务流程分析过程中应该以部门级作为主线索，并针对岗位级进行细化，针对组织级进行抽象概括。
17、流程通常分为三类：生产性流程、管理性流程、支持性流程。
18、流程分析完毕之后需要进行瓶颈和利益分析，一般需要消除瓶颈
19、业务实体分析过程中除非十分熟悉ER图，否则建议采用类图，这里的类图并不等价于开发过程中的类图，而是类型图的意思。
20、需求建模时，使用类图过程中应该大胆使用中文来表示类名和属性名，但不必像设计阶段那样添加很多辅助建模元素。
21、领域建模过程中广泛采用“名词动词法来标识类。
22、导航性、角色名、导出属性、限定符、约束等修饰属性需要根据类图情况来确定是否需要加入。
23、领域建模过程中不要考虑成员方法，行为需求应该放到流程图和用例图中描述，确定类的操作属于设计范畴无需对客户明示；不要先去明确关联的多重性；不要考虑业务类的通用性；不要过度分析名词和动词；不要过多讨论聚合和组合表示；不要将类的名称弄得难以理解，需要直观；不要关心友元关系和参数化等具体实现；不要先直接映射到数据库表结构；忘记设计模式；不要过早合并子类；不要分拆大类；不要过早抽象同类。拒绝实现、保持简单、忠于问题域。
24、概念模型（设计）和物理模型（设计）区分：概念模型（设计）属于需求视图，物理模型（设计）属于开发视图。
25、用例图仅仅是一个针对用例描述的目录，用例描述是封装所有需求的形式。
26、用例图中参与者多半可以用角色替代，但不仅仅由人承担，参与者可能是其他系统、硬件设备、时钟等。
27、CRUD动作名词和业务名词在用例名称一起使用时需要仔细注意是否会掩盖实际用例。
28、用例命名建议采用业务动词命名，避免系统动词加业务名词方式，但对系统创建的东西则不尽然。
29、采用基本事件、扩展事件、子事件的方式来描述会比冗长的if else描述要好多。
30、界面原型不应该是解决方案，应该是客户对业务的要求和约束，应该是需求人员的实现建议；开发人员不应该画地为牢，界面原型目的是支持有效的UI设计。