软件需求分析知识点

核心工作流
组织要解决什么问题？——业务建模
为了解决组织的问题，新系统应提供什么功能和性能？——需求
为了提供功能，系统内部应该有什么样的核心机制？——分析
为了满足性能，系统的核心机制如何选定技术实现？——设计
需求目标是提升销售，设计的目标降低成本。



UML
UML的统一
开发人员喜欢画“草图”，是以形式的粗陋，遮掩内容的粗陋。
过程改进（战术）需要技能（技术）的支撑，所以需要UML作为技能（技术）。
UML的14种图
用例图
描述结构的：类图、对象图、组件图、部署图、包图、组合结构图
描述行为的：序列图、通信图、状态图、活动图、交互概述图、时间图
总则图
愿景
愿景是在老大看来，引进这个系统的目的。
愿景必须来自老大。
愿景必须指出度量的指标。
愿景描述的例子：

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

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

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



业务建模
选定愿景要改进的业务组织
组织可以是正式的也可以是非正式的。
某通信公司要做TL9000的贯标工作，需要开发一个系统来管理贯标事物，如果要做业务建模，研究对象选什么组织比较合适？——贯标工作组
要做一个帮助中小企业发布信息的网站，想通过业务建模来获取需求，如何选择适当的组织来研究？——中小企业
要做一个助威设备，让李宇春歌迷更好地支持李宇春，如何选择适当的组织来研究？——玉米
业务用例图和业务序列图
从外部看：价值的集合——业务用例图。
从内部看：系统的集合——业务序列图。
业务执行者：在组织之外和组织交互的人群或组织。
业务工人：在组织内部和组织交互的人。
业务实体：在组织内部和组织交互的非人实体。
业务工人和业务实体可以相互取代责任。
业务用例描述的是组织为业务执行者提供哪些价值。
用活动图和序列图来详述业务用例。

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

在业务序列图中

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



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



业务流程的改进点

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

阿布思考法：先不考虑资源的限制，得出完美方案。然后根据现有资源去模仿山寨。
需求
系统用例图
系统执行者

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

什么时候Windows算执行者？调用驱动程序的时候。
特别的外系统：时间
“非人”执行者会越来越多
用例的独特优势：演员与观众分开。系统执行者是演员，涉众是观众。
主执行者和辅执行者



用例是能卖的价值：对于ATM机，登录不是用例，取款和查询余额才是用例。
用例多大（粒度）——期望、契约、承诺
业务序列图帮助理清责任。多少个箭头就有多少个用例。
研究对象改变，用例也随之而变。
最常犯“粒度”错误：把步骤当作用例。
需求是不“复用”的，“复用”的是设计。
书写用例文档
总原则：如果涉众不能理解和验证，它就不是需求（如果删掉它，会不会有涉众的正当权益受侵害？）
同样的目标，不同的涉众利益，会有不同的过程。
用例要平衡涉众之间的利益。
涉众经常来自于当事人、上游、下游、操作对象的主人……
交互四步曲：请求、验证、改变、回应。
用例书写应该可理解可验证（说人话）

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

什么时候需求里可以出现SQL字样？做DB工具的时候；老大要求实现的手段的时候。
书写的时候主语只能是执行者或系统。
书写的时候不要涉及界面组件。像这些是不对的：会员从下拉框中选择类别；会员在相应的文本框中输入查询条件，会员点击确定按钮。在写路径步骤的时候，要问一下自己“不这样行吗”？
补充约束可以直接放在用例中，也可以单独集中到另外的文档，从用例文档指向。

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

识别用例的关系

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



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



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



需求启发
需求工程师综合不同涉众的利益编出需求。涉众无资格、无责任提供需求。需求启发的时候，交流内容聚焦于涉众利益。
客户看不懂UML怎么办？客户不接受用例文档怎么办？模型和视图分离，与客户交流的形式采用视图。
如果涉众直接给出需求怎么办？只当作材料，供需求过程中参考和提炼。
需求启发技术：研究资料、问卷调查、访谈、观察、研究竞争对手。
涉众代表必须名副其实。涉众代表 != 部门主管。应该选择经验丰富的涉众（老师傅型的，系统就是为了学习他的经验）。
研究竞争对手
类型（左右划线）

防御战：领先者完善自己，进攻另外的领域（Google vs Google，微软 vs 微软）

进攻战：攻击领先者强势中的弱点（Compaq vs IBM，Nokia vs Motorola）

侧翼战：在无人区发动突击（各种创新）
游击战：紧紧守住小块市场（地区报纸，小区商店）

攻击优点背后不可更改的缺陷。比如麦当劳定位于儿童，风格活泼。此风格无法有效覆盖成熟人群，Burger King就定位于11岁以上的绅士，以获取市场。

老牌——陈旧
市场占有率高——不能为每个客户精心服务
聪明——不稳重
有钱而且帅——花心

分析
分析：提炼核心域知识
设计：添加非核心域知识
人脑对机理的把握度是有限的，所以必须分解机理。面向对象分解为对象的协作，面向过程是功能分解。面向对象的分解比面向过程的分解更好是因为人脑更容易把握。
类的关系

泛化（静态）
关联（静态）
依赖（动态）

泛化是集合之间的关系，关联是个体之间的关系



识别关联

连接（直线）
聚合（空心菱形）：整体与部分的生命周期不同
组合（实心菱形）：整体与部分的生命周期一样

考虑的出发点：责任分配
出题：根据一段文字画类图。练习P10
序列图和类图的映射
序列图中
消息的传入：类的操作——责任
消息的传出：类完成操作所需合作——协作
箭头代表责任分配而非数据流动
责任分配
交互原则

专家原则——资源决定消息内容
老板原则——由老板发送消息给我
可视原则——只发消息给朋友

状态图
属性值变化导致行为发生变化——转换
假设状态图是对的，序列图错在哪里？？？
彩色建模