第1章笔记：从问题到可验证需求

本章目标

先理解利益相关者、问题边界与验收证据，再写需求文档。 本章不是术语表，而是一条从问题到证据的工作链。先确认用户或团队要保护的结果，再把决定写进可版本化制品，最后由测试、指标、反例或演练证明它在边界与故障下仍成立。

七节联系

• 软件工程不是把代码写长：软件工程处理多人、长期、变化和风险；代码只是实现制品之一；关键规则是一个需求只有在责任人、输入、可观察结果和失败边界都明确时才可进入开发。
• 识别利益相关者与真实目标：提出功能的人不一定是承担后果的人，要区分购买者、使用者、运维者和受影响者；关键规则是目标写成可测结果；方案只是候选，不得把‘做一个小程序’冒充问题定义。
• 访谈、观察与证据三角验证：访谈得到陈述，观察得到行为，数据得到频率；三类证据互相校准；关键规则是至少用两种独立来源验证关键假设，并把冲突保留为待决问题。
• 用户故事、用例与验收条件：用户故事表达价值切片，用例描述交互路径，验收条件把模糊期望变成可判定事实；关键规则是验收条件应覆盖正常路径、边界、权限和故障，不使用‘友好’‘快速’等不可判词。
• 非功能需求与质量属性场景：性能、可靠性、安全、可维护性必须写成刺激—环境—对象—响应—度量；关键规则是质量属性必须有测量环境和阈值；平均值不能代替尾延迟与故障时表现。
• 需求优先级与范围切片：优先级由价值、风险、依赖和成本共同决定，不是声音最大者优先；关键规则是每个切片都要端到端可验收；不能把数据库、后端、前端分别称作三个用户价值。
• 需求基线、追踪与变更控制：基线不是冻结变化，而是让每次变化有来源、影响和决策记录；关键规则是变更前做影响分析，变更后同步需求—设计—代码—测试—运维证据链。

学习时给七节画依赖箭头：前一节产出的对象、规则或制品如何成为后一节输入？若某节可以被随意挪走而完全不影响上下文，说明你仍在孤立背诵，需要用一个贯穿案例重新连接。

章内练习

1. 用“为校园活动平台画出用户、维护者、财务和安全人员的责任边界，并列出上线后三个月仍需维护的承诺”重做正常、边界和故障三类验收，产出可由同伴复核的制品。
2. 用“预约系统希望提高利用率，但学生关心操作时长，管理员关心爽约，残障用户关心可达性”重做正常、边界和故障三类验收，产出可由同伴复核的制品。
3. 用“访谈说审批只需两步，现场却出现纸质签字、电话确认和月底补录，日志又显示退回率高”重做正常、边界和故障三类验收，产出可由同伴复核的制品。
4. 用“‘作为助教，我要批量延长截止时间’要补权限、选课范围、时区、通知与失败回滚”重做正常、边界和故障三类验收，产出可由同伴复核的制品。

每次练习都保留背景、输入、决定、输出、验证、失败处置和负责人。只写结论不算完成；只贴截图也不算证据。完成后交换给同伴，只允许对方根据制品复现你的判断，无法复现处就是下一轮修改入口。

错误复盘

把错题标成目标误判、边界遗漏、责任空缺、契约不清、验证不足或恢复缺失。不要写“粗心”。一周后更换领域重做一道情境题；能在新名词下保持同一证据链，才说明方法已经迁移。阶段卷使用独立题池，不能靠记住随课题答案过关。