业务流程建模防止需求遗漏的判断流程

[[需求分析三套实践论：小、中、大方法]]中大型方法防止需求遗漏，靠的是两条相辅相成的经验，用PM Suite案例可以演示具体如何落地。第一条经验是业务流程：尽可能广泛地勾画各种可能的业务场景进行业务流程建模，识别需要哪些业务步骤——这些业务步骤（或几个步骤组成的片段）是发现”IT系统应该提供的功能（用例）”的最佳研究点。关键技巧是在需求分析过程中明确判断每个业务步骤属于三种类型之一：全手工型（不会产生系统需求，比如”组建项目团队”这种应该由项目经理亲自完成、不推荐靠IT系统辅助的步骤，判断后不发现用例）、IT辅助型（又称半手工型，会产生系统需求并伴有人机交互要求，比如”制定进度计划”这种判断后确认需要IT系统帮助，因此发现用例）、IT全自动型（会产生系统需求，多为后台自动服务）。第二条经验是角色找全：尽可能把用户角色找全，否则秉承”以用户为中心”思想的用例建模过程就难保不遗漏需求——角色查找同样要覆盖全类型：系统需要和哪些外部系统交互、谁使用系统的主要功能、谁需要系统支持日常工作、谁来维护管理使系统正常工作、系统需要操纵哪些硬件。这两条经验相辅相成使用：比如想到了”系统管理员”这个角色后，回头再查业务流程，往往会发现漏掉了很多”辅助性流程”（面向核心业务功能的流程一般不会被遗忘，但辅助性流程很容易被忽视），这时就需要继续对辅助流程做分析，从而发现更多用例。PM Suite案例的具体操作是：先用UML活动图绘制高层业务流程图，再对过于复杂的业务步骤（如”项目计划”）层层展开成子业务流程递归分析，然后对每个业务步骤依次判断”粒度是否够小”→”属于哪种类型”→”是否需要新增用例”。

结构图：

flowchart TD
    A["识别一个业务步骤"] --> B{"粒度是否够细？\n（不需要再分解）"}
    B -->|否，继续分解| C["展开为子业务流程\n（递归回到A）"]
    B -->|是| D{"判断步骤类型"}
    D -->|全手工型| E["不发现用例\n（如'组建项目团队'）"]
    D -->|IT辅助型/半手工型| F["发现用例，加入用例图\n（如'制定进度计划'）"]
    D -->|IT全自动型| G["发现用例（后台自动服务）"]