【软件系统架构案例每日深耕 Day 18】质量属性场景驱动的需求分析

【Day 18】质量属性场景驱动的需求分析

一、题目还原

某三甲医院计划建设"智慧门诊"信息系统，覆盖线上预约挂号、分时段就诊、电子病历调阅、检查检验报告查询、在线缴费等业务。医院信息科牵头进行需求分析，业务科室（门诊部、药剂科、检验科、财务科）与患者代表提出了大量"功能需求"，但信息系统建设方发现：需求文档中缺乏对非功能性需求（质量属性）的系统性描述，导致项目启动后多次出现方案返工。

典型问题包括：
(1) 门诊部要求"预约挂号系统必须稳定可靠"——但"稳定可靠"到底指什么、如何验收，没有量化定义；
(2) 患者代表提出"查询报告要快"——但快是1秒还是5秒？高峰期（周一上午）和平时要求是否相同？
(3) 财务科要求"缴费系统必须安全"——但安全包含哪些方面（认证/授权/加密/审计）？保护哪些数据？
(4) 检验科要求"系统将来能扩展"——但扩展是指加功能、加用户还是加设备？成本约束如何？
(5) 院方要求"系统升级不能影响门诊运行"——升级窗口、停机容忍度、回滚要求均未明确。

架构师决定采用**质量属性场景驱动（六要素场景构建法）**重构需求分析过程，将模糊的"形容词需求"转化为可度量的质量属性场景，并输出结构化需求文档。

【Q1】（8分） 请说明质量属性场景六要素的内容，并解释为什么"稳定可靠"“快”“安全”"能扩展"这类表述不能直接作为架构设计的输入。

【Q2】（10分） 请针对上述5项典型问题，分别构建一个完整的质量属性场景（六要素齐全），并给出可验收的量化指标。

【Q3】（7分） 请说明基于质量属性场景的需求文档应包含哪些核心内容（需求文档模板要素），并分析场景驱动需求分析与传统功能需求分析的关系。

二、考点分析

三、标准答案（采分点格式）

【Q1】六要素内容与模糊需求的缺陷（8分）

（1）质量属性场景六要素（3分）：

刺激源（Source）→ 刺激（Stimulus）→ 环境（Environment）→ 制品（Artifact）→ 响应（Response）→ 响应度量（Measure）

（速记口诀：源→刺→环→制→应→度）

（2）模糊表述不能作为架构设计输入的原因（5分）：

① 不可度量、无法验收："稳定可靠"没有量化标准（可用性99.9%还是99.99%？），验收时无法判定是否达标；
② 缺少环境边界："要快"没有区分平时与高峰期——架构设计必须针对最坏环境（峰值）设计，否则高峰即崩溃；
③ 多义性、理解歧义："安全"可指认证、授权、加密、审计、防注入等多方面，不同干系人理解不同，导致设计偏差；
④ 缺少制品定位：“能扩展"没指明扩展对象（功能/用户/数据量）与约束（成本、时间），架构师无法确定扩展策略（水平扩展vs垂直扩展vs微服务拆分）；
⑤ 无法映射战术：架构战术的选取依赖具体场景——只有知道"什么环境下、多大量级、要求多少度量”，才能匹配缓存、冗余、限流等战术。模糊需求使架构决策失去依据，必然返工。

【Q2】五类问题场景构建（10分，每个2分）

场景1：可用性（对应"稳定可靠"）

• 刺激源：基础设施故障（服务器宕机）
• 刺激：预约挂号服务所在服务器宕机
• 环境：周一上午就诊高峰
• 制品：挂号服务集群
• 响应：自动检测故障并切换至备用节点，患者无感知继续挂号
• 响应度量：系统可用性≥99.9%（年停机≤8.76小时）；故障切换RTO≤30秒，挂号数据零丢失（RPO=0）

场景2：性能（对应"查询要快"）

• 刺激源：患者（大量并发查询）
• 刺激：周一高峰同时发起10万次报告查询请求
• 环境：系统高峰期满负载状态
• 制品：报告查询服务与数据库
• 响应：缓存命中热点报告，快速返回查询结果
• 响应度量：峰值P99响应时间≤2秒，平时P99≤500ms；吞吐量≥1000 QPS

场景3：安全性（对应"必须安全"）

• 刺激源：未授权用户/攻击者
• 刺激：试图越权调阅他人电子病历、篡改缴费数据
• 环境：系统对外提供服务（含互联网渠道）
• 制品：病历服务、缴费模块、API网关
• 响应：网关鉴权+RBAC权限校验拒绝访问，敏感数据加密存储与传输，操作记录审计日志
• 响应度量：100%未授权访问被拦截；病历与支付数据加密覆盖率100%；审计日志完整可追溯（满足《数据安全法》《个人信息保护法》）

场景4：可修改性（对应"将来能扩展"）

• 刺激源：检验科/信息科
• 刺激：新增检验设备类型、新报告格式或新业务模块（如互联网医院）
• 环境：系统生产运行中
• 制品：检验报告服务、集成接口
• 响应：通过标准化接口/插件化方式接入新设备与新模块，不影响现有功能
• 响应度量：新增一种检验设备接入≤5人天；新增业务模块上线≤2周；受影响服务数≤1个

场景5：可测试性/部署（对应"升级不影响运行"）

• 刺激源：运维/信息科团队
• 刺激：系统大版本升级
• 环境：门诊正常运行期间（白天不可停机）
• 制品：核心业务链路（挂号/缴费/报告）
• 响应：灰度发布+滚动升级，新旧版本并行，流量逐步切换，异常自动回滚
• 响应度量：升级过程零停机；灰度验证周期≤1周完成核心链路回归；回滚时间≤10分钟

【Q3】需求文档模板与两类需求的关系（7分）

（1）场景驱动需求文档的核心内容（4分）：

（注：与传统需求文档相比，第③④⑥条是场景驱动方法的特有强化部分）

（2）场景驱动需求分析与传统功能需求分析的关系（3分）：

① 互补而非替代：功能需求回答"系统做什么"（用例/用户故事），质量属性场景回答"系统做得怎么样"（六要素+度量）——两者共同构成完整需求基线；
② 功能需求是场景的素材来源：质量属性场景的"刺激"往往来自功能操作（如"并发挂号"是功能"挂号"在高峰期的属性化描述）；
③ 场景驱动提升需求完备性：传统分析侧重功能遗漏，场景驱动补上非功能性遗漏——本题医院项目正是因NFR缺失导致返工，用六要素法将模糊形容词"翻译"成可验收指标，使需求可度量、可测试、可追踪（需求追踪矩阵：每个场景→对应架构战术→对应测试用例）。

四、评分要点

必答采分点：

1. Q1：六要素名称与含义完整（3分）；模糊需求缺陷至少答出3条且理由充分（3分）；
2. Q2：5个场景六要素齐全（每个2分，共10分）——缺要素扣分；量化指标必须出现在"响应度量"中；
3. Q3：需求文档要素至少列出5项且包含"质量属性场景+验收标准"（3分）；两类需求关系（互补、素材来源、完备性）至少2点（2分）。

加分项：

• 场景度量指标与医院场景贴合（周一高峰、RTO 30s、等保三级、个保法）；
• 提到"需求追踪矩阵"（场景→战术→测试用例）；
• 指出"性能场景必须按峰值环境设计"（环境要素的意义）；
• 关联Day 14/15（六要素是ATAM效用树场景的源头）。

常见失分点：

• 把"质量属性需求"写成功能需求（如"支持支付宝缴费"是FR不是NFR）；
• 场景中"响应度量"缺失或无量纲（只写"要快"不写"P99≤2s"）；
• 需求文档模板遗漏验收标准/优先级；
• 混淆"架构约束"与"质量属性"（国产化要求是约束，不是质量属性）。

五、扩展知识点

1. 关联Day 14（周测：场景构造+战术匹配）： Day 14考"识别属性→构造场景→匹配战术"，本题考"用场景方法做需求分析"——两者共用同一套六要素工具，但视角不同：Day 14是"架构师视角"（评估/设计），Day 18是"需求工程师视角"（捕获/规格化）。六要素是贯穿需求→设计→评估的主线。

2. 关联Day 15（ATAM）： ATAM效用树的第三层场景就是质量属性场景——需求阶段构建的场景，可以直接"搬运"进ATAM效用树评估。这正是"场景驱动"的闭环价值：需求场景→效用树→评估场景，一套场景贯穿全生命周期。

3. 关联《易混淆对照表》： 质量属性 vs 架构约束——“必须使用国产数据库”"满足等保三级"是约束（不可变更的外部条件）；"挂号响应P99≤2s"是质量属性（可通过架构手段优化）。考题陷阱：把约束当质量属性写进NFR。

4. 关联《软件工程-需求工程》： 需求分析四步（需求获取→需求分析→需求规格说明→需求验证）——质量属性场景构建属于"需求分析+规格说明"阶段；“需求追踪矩阵”（场景↔架构决策↔测试用例）属于需求管理。

5. 关联《必背公式速查卡》： 场景量化指标可复用速查卡数值：可用性99.9%（年停机8.76h）/99.99%（52.56min）；响应时间P99/P95；吞吐量QPS/TPS；RTO/RPO——写度量时直接引用标准数值，增强专业度与一致性。

六、今日金句

“需求分析中最危险的词是形容词——‘稳定’‘快’‘安全’‘可扩展’都不可验收；质量属性场景六要素是’形容词翻译机’：把’系统要稳定’翻译成’服务器宕机时（刺激）系统在高峰（环境）下30秒内切换（响应），数据零丢失（度量）'——可度量的需求，才是可设计的架构。”

（考试原话级表述，可直接用于需求分析类案例结论段或论文需求分析章节。）