准备需求分析的考试

核心工作流

组织要解决什么问题？——业务建模

为了解决组织的问题，新系统应提供什么功能和性能？——需求

为了提供功能，系统内部应该有什么样的核心机制？——分析

为了满足性能，系统的核心机制如何选定技术实现？——设计

需求目标是提升销售，设计的目标降低成本。

UML

UML的统一

开发人员喜欢画“草图”，是以形式的粗陋，遮掩内容的粗陋。

过程改进（战术）需要技能（技术）的支撑，所以需要UML作为技能（技术）。

UML的14种图

用例图

描述结构的：类图、对象图、组件图、部署图、包图、组合结构图

描述行为的：序列图、通信图、状态图、活动图、交互概述图、时间图

总则图

愿景

愿景是在老大看来，引进这个系统的目的。

愿景必须来自老大。

愿景必须指出度量的指标。

愿景描述的例子：

• 减少采集数据所花费的时间
• 提高制作动画的速度
• 缩短订单的处理周期

不是愿景的描述（通常是解决方案或功能而不是愿景）：

• 建立一个CRM系统
• 提供在线订机票功能
• 能够进行风险评估

业务建模

选定愿景要改进的业务组织

组织可以是正式的也可以是非正式的。

某通信公司要做TL9000的贯标工作，需要开发一个系统来管理贯标事物，如果要做业务建模，研究对象选什么组织比较合适？——贯标工作组

要做一个帮助中小企业发布信息的网站，想通过业务建模来获取需求，如何选择适当的组织来研究？——中小企业

要做一个助威设备，让李宇春歌迷更好地支持李宇春，如何选择适当的组织来研究？——玉米

业务用例图和业务序列图

从外部看：价值的集合——业务用例图。

从内部看：系统的集合——业务序列图。

业务执行者：在组织之外和组织交互的人群或组织。

业务工人：在组织内部和组织交互的人。

业务实体：在组织内部和组织交互的非人实体。

业务工人和业务实体可以相互取代责任。

业务用例描述的是组织为业务执行者提供哪些价值。

用活动图和序列图来详述业务用例。

• 活动图往往只表现动作。
• 序列图强迫思考背后的目的。

在业务序列图中

• 消息的名字——责任和目的。A请求B做某事。

• 消息的方向——责任委托，不是数据流动。

业务流程的改进点

• 改善信息流转
• 封装复杂的逻辑

阿布思考法：先不考虑资源的限制，得出完美方案。然后根据现有资源去模仿山寨。

需求

系统用例图

系统执行者

• 在系统外，与系统作有意义交互的系统
• 代表了功能需求
• 与重要无关

什么时候Windows算执行者？调用驱动程序的时候。

特别的外系统：时间

“非人”执行者会越来越多

用例的独特优势：演员与观众分开。系统执行者是演员，涉众是观众。

主执行者和辅执行者

用例是能卖的价值：对于ATM机，登录不是用例，取款和查询余额才是用例。

用例多大（粒度）——期望、契约、承诺

业务序列图帮助理清责任。多少个箭头就有多少个用例。

研究对象改变，用例也随之而变。

最常犯“粒度”错误：把步骤当作用例。

需求是不“复用”的，“复用”的是设计。

书写用例文档

总原则：如果涉众不能理解和验证，它就不是需求（如果删掉它，会不会有涉众的正当权益受侵害？）

同样的目标，不同的涉众利益，会有不同的过程。

用例要平衡涉众之间的利益。

涉众经常来自于当事人、上游、下游、操作对象的主人……

交互四步曲：请求、验证、改变、回应。

用例书写应该可理解可验证（说人话）

• 错：系统建立连接，打开连接，执行SQL语句，从“零件”表查询……
• 对：系统按照查询条件搜索零件

什么时候需求里可以出现SQL字样？做DB工具的时候；老大要求实现的手段的时候。

书写的时候主语只能是执行者或系统。

书写的时候不要涉及界面组件。像这些是不对的：会员从下拉框中选择类别；会员在相应的文本框中输入查询条件，会员点击确定按钮。在写路径步骤的时候，要问一下自己“不这样行吗”？

补充约束可以直接放在用例中，也可以单独集中到另外的文档，从用例文档指向。

• 字段列表
• 业务规则
• 非功能需求：可用性、可靠性、性能、可支持性
• 设计约束

识别用例的关系

• 扩展：分离扩展路径。扩展路径是一定会必须执行的。通常是一个用例有多个扩展路径。

• 包含：提供公共步骤集合，便于复用。被包含的步骤不一定被执行。通常是多个用例包含一个可以复用的步骤

• 泛化：统一业务目的的不同技术实现

参考

潘加宇老师的讲义