-10-13《软件需求最佳实践》徐锋著
第12章SERU过程框架总结
“我们并不缺乏软件工程、需求工程的理论、技术，缺乏的是将这些理论与技术有效地应用到实践中去的具体方法。”
1SERU过程框架要点概述
SERU是4个单词的首字母：
●S：SubjectArea的首字母，它表示子问题域；这是“信息工程”中的概念，核心的思想就是根据业务区划来分解系统，使系统的各个部分在业务上保持相对独立，降低耦合性。
●U：UseCase的首字母，也就是用例，这是RUP之父Ivar博士发明的一种需求技术，它是迄今为止应用最广泛的技术之一；在笔者的实践中，发现它是封装需求的最好手段，可以作为需求组织的最小单位：一个业务活动（B类用例）、一个具体的报表项（R类用例）、一个具体的接口（I类用例）。
●E：Event的首字母，表示事件（对于信息系统而言就是业务事件），它是流程的起点，最早源于实时系统的需求分析，后来被结构化分析方法之父DeMarco引入到业务软件的分析中；通过业务事件的标识，就能够找到流程，通过流程就可以有效地将不同的场景串接在一起，起到承上启下的关键一环，它覆盖了OLTP（联机事务处理）部分的需求。
●R：Report的首字母，表示查询、分析、统计，用来覆盖MIS（管理信息系统）部分的需求；通过寻找管控点（也就是从意图出发），以确定报表类型，然后再细化到具体报表项。
A需求定义阶段●对应的软件生命周期阶段：这个阶段对应于项目立项阶段，也就是RUP中定义的初始（先启）阶段。
●核心工作：
1）判断系统的规模，决定是否划分成不同的主题域；
2）若需要，则根据业务特点（可从分管领导找线索）划分主题域；
3）讨论每个主题域的范围，可用上下文关系图表示；
4）针对每个主题域，列出事件、报表类型列表。
●主要产物：
1）构件图，用来表示主题域之间的关系，通常只有1张；
2）上下文关系图，表示主题域的范围，张数与主题域个数相等；
3）业务事件列表、报表类型列表。
●主要访谈对象：中高层用户代表。
●重要信息：
1）组织结构图、分管领导，有助于主题域划分；
2）部门职责说明，有助于主题域间服务接口的标识。
●其他提示：这个阶段所花的时是比较简短的，不求标识出全部的业务事件和报表类型；重点在于从宏观层面理解业务，标识出最主要的业务事件和报表。
●剪裁说明：
1）对于规模较小的系统，不必划分主题域；
2）对于涉及原系统的项目，可能标识出新主题域和原有主题域。
B理清需求框架和脉络阶段●对应的软件生命周期阶段：这个阶段对应于需求捕获、分析的一阶段，也就是RUP中定义的细化阶段的第1次迭代，结束标志是“标识出绝大多数的用例”。
●核心工作：
1）针对每个业务事件进行流程、业务实体、使用场景分析；
2）针对每类报表进行业务实体、使用场景分析；
3）将前面标识出来的所有场景（用例）进行抽象，得到用例模型；
4）将前面业务实体分析获得的领域模型片段进行合并与抽象。
5）对设计约束与质量属性进行分析。
●主要产物：
1）活动图（或数据流图、跨职责流程图），用来表示业务流程；
2）领域类图片段，表示每个业务流程、报表类型涉及的业务实体；
3）用例模型片段，表示每个业务流程中的业务活动、具体报表项；
4）领域模型：按主题域对领域类图片段进行合并与抽象；
5）用例模型：按主题域对用例模型片段进行合并与抽；
6）部署图：用来描述软、硬件环境方面的设计约束。
●主要访谈对象：中层用户代表。
●上阶段产物应用：
1）业务事件、报表类型列表作为访谈计划的线索；
2）业务事件、报表类型列表作为需求组织的二级目录。
●其他提示：这个阶段主要是搭框架，不要涉及太深的内容；目标不在于标识所有用例、所有的领域类，而是标识出最重要的部分。另外，在本阶段完成后将对需求进行基线划分。
●剪裁说明：
1）对于业务流程不太明晰的小项目，可以越过流程分析；
2）对于涉及原系统的项目，可能标识出新业务事件和老业务事件。
C填充需求细节阶段●对应的软件生命周期阶段：这个阶段对应于需求捕获、分析的二阶段；对于RUP而言，将通过多次迭代完成，对应于细化阶段的后续迭代和构建阶段的前期迭代，结束标志是“已标识用例、领域类的细节均填充完毕”。
●核心工作：
1）针对每个用例（B、R、I）类进行捕获、分析；
2）对流程图上标识的相关文档进行分析，完成领域类的细节填充；
3）在架构师的支持下，完成技术类用例的描述。
●主要产物：
1）业务类用例描述，包括事件流、相关需求、UI原型、规则约束；
2）报表类用例描述，包括报表概述、报表内容和输入/输出格式；
3）接口类用例描述，包括使用者概述、内容与格式、实现约束；
4）领域类描述：包括数据窗口分析、组成与格式、计算规则。
●主要访谈对象：操作层（及小部分中层）用户代表。
●上阶段产物应用：
1）根据上阶段得出的用例模型，按基线安排调研与细化；
2）根据用例所关联的领域类，安排领域类的分析与细化。
●其他提示：对于技术类用例而言，建议由架构师进行组织，细化的方法可以自由地确定。另外，如果需求人员时间比较紧张，可以考虑在关键用例细化完成之后，由开发人员接手其他用例的细化工作。
小婧：作者介绍的其实都是套路。我经常遇到有人问我要模板，各种模板。有些特别是别的岗位转来做需求分析或者刚开始做需求分析的小伙伴，没有形成一套自己的分析套路和方法，这本书就会特别的实用。因为作者介绍的这个框架适合于各种类型的产品。有的人说，我们是互联网产品，根本就没搞这么复杂，就做做用户画像，画画原型，写写需求规格。但是你要知道，很多东西没有经过这种系统的分析，后期是需要还债的。也不是说，你每一步都要按照书上的来，只是说，你自己可以根据书上的思路去思考，遇到一个需求应该怎么处理，为什么这么处理，我期望得到什么结果。有的小伙伴总是抱怨没人带，没有师傅领进门。现在有这么一个框架，你可以参考，吃透了就算是入门了。而针对做了多年的需求的小伙伴来说，这本书可以帮你查漏补缺，找出你工作中缺失、薄弱的部分。可能你看过后，恍然大悟，原来就是因为这个工作没有做充分导致了上次那件悲催的事件。2需求实作要点概述
A需求定义勿忽视需求定义严格来说是项目立项的工作，换句话说，在进行需求开发时，定义应该已经完成了。但实际上这方面的工作经常存在偏差，因此我们需要进行补课。补课的内容主要包括两个方面：
●项目目标：目标决定范围，没有对业务目标进行分析，就难以控制范围；企业级的目标（也就是系统要解决企业什么问题、创设什么机会）有时很难定义，但Stakeholder的北京哪个医院治疗白癜风专业北京哪里治疗白癜风手术好