需求分析在用例设计中的应用
用例设计到底该怎么入手？很多人上来就写用例，写出来才发现——要么漏场景，要么边界没覆盖，要么完全跑偏。说白了，根子出在需求分析上。
你想想看，需求都没吃透，用例怎么可能写得对？
我个人的习惯是，拿到一份需求文档，先别急着开写，花30%的时间做需求分析，后面70%的用例设计会顺畅很多。
核心观点： 需求分析的深度，决定了用例设计的质量。不理解需求，用例就是空中楼阁。
为什么需求分析是用例设计的起点
我见过太多团队，上来就写用例，结果写到一半发现需求没搞明白，又回去翻文档。一来二去，用例质量差不说，进度还拖了。
需求分析解决三个核心问题：
- 到底要测什么 —— 业务目标、用户场景
- 怎么才算对 —— 功能行为、预期结果
- 边界在哪 —— 输入范围、异常处理
你想想看，这三个问题不搞清楚，用例就是凭感觉写。凭感觉写出来的东西，覆盖率能高吗？
我的习惯： 拿到需求后，先花15分钟画出"需求→功能→场景