Community研究与数据分析github.com

vlaskos/需求摘要到架构分析

将原始的需求摘要、RFP、调研转录稿或功能规格转化为架构级别的分析——提取出架构上重要的需求,将其拆分为功能/质量属性/约束三类,使每条需求可测试,按业务价值和架构影响排序,检查是否存在隐性冲突,并转化为可衡量的质量场景及相应的设计策略。

需求摘要到架构分析 是什么?

该技能旨在将非结构化的原始输入(如需求摘要、投标文件(RFP)、调研访谈记录或功能规格)转化为严密的架构分析。它通过一个六步流水线工作:提取真实需求、分类(功能/质量属性/约束)、精炼可测试表述并按架构影响排序、评估可行性以发现矛盾、最后生成可衡量的质量场景并选择设计策略。该技能以ISO/IEC 25010质量标准为锚点,确保质量属性覆盖的完整性,并提供了专门的参考文件(如ASR框架、质量模型、可行性检查、设计策略等)。它适用于任何需要在估算或设计前评估需求集(包括预销售输入、启动文档)的场景,帮助回答“哪些需求在架构上显著”、“需求间是否存在冲突”以及“如何在架构决策中做出权衡”等问题。

兼容平台~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/vlaskos/brief-to-architecture/tree/HEAD

Installed? Explore more 研究与数据分析 skills: affaan-m/uspto-database, affaan-m/scholar-evaluation, affaan-m/literature-review · View all 6 →

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

架构显著需求(ASR)分析

一份需求摘要不是一个规格。它是一堆愿望、假设和半陈述的约束,而其中埋藏着几个真正会决定系统形态和成本的少数需求。本技能找出它们,使其精确,并在任何人承诺估算或设计之前,让它们相互验证。

架构显著需求(ASR) 是指对架构有可测量影响的需求:满足它会迫使你做出结构选择、约束一项技术、设定一个难以达到的质量门槛,或者与其他需求交互从而限制你的选项。一份摘要中的大多数需求 并非 架构显著。任务是将关键的少数从多数中分离出来,并说明每一条为何重要。

这项工作在质量属性方面的基础是 ISO/IEC 25010,国际标准产品质量模型。使用一套标准的质量特性可以确保分析的完整性(每次都检查相同的维度),并为所有参与者提供共享的词汇。参见 references/quality-model.md。

流水线

将需求摘要运行通过六个步骤。每一步都会产生供下一步使用的产物。

  1. 提取,而非转录。 阅读原始输入,提取出真正的需求,包括那些以功能、抱怨或随口之言形式表述的需求。像“我们的黑色星期五流量是正常的40倍”这句话,不是功能需求,而是一个伪装成性能与可伸缩性需求的真实需求。需要解读。关于如何识别架构显著的需求,参见 references/asr-framework.md。

  2. 分类。 将每个提取出的需求归入三个类别之一:

    • 功能性 — 系统必须 做什么。
    • 质量属性 — 系统必须做到多好(性能、可靠性、安全性、可维护性等)。使用 ISO/IEC 25010 的特性,确保每次都覆盖同样的领域——references/quality-model.md。
    • 约束 — 固定、不可协商的边界(强制使用的技术、法规、截止日期、现有系统)。约束不能用于设计;它们会塑造一切其他方面。
  3. 精炼。 重写每条重要需求,使其无歧义且可测试,并说明其 架构影响 —— 如果认真对待该需求,会带来怎样的结构后果。去除作者偷偷塞入的方案(“使用 Kafka”是实现机制,不是需求;需求是它背后的吞吐量或解耦能力)。无法测试的需求,就无法估算。

  4. 双轴优先级排序。 并非每个 ASR 都值得同等关注。对每条按以下两个维度排序:

    • 业务价值 — 结果对客户的重要性。
    • 架构影响 — 它对设计的约束程度以及撤销的成本(高影响关乎 不可逆性和影响范围,而非工作量)。 两者都高的需求是真正决定架构的地方。将你的分析集中于此。参见 references/scenarios-and-priorities.md。
  5. 检查可行性。 在设计任何东西之前,检查高优先级的需求能否 共存。最危险的需求摘要往往内部矛盾:延迟目标、一致性目标和成本上限不可能同时成立。见 references/feasibility-check.md 获取具体方法,包括针对数值需求的算术检查方法。

  6. 指定场景并选择策略。 对于高优先级的质量属性,编写 可测量的质量场景(触发器、环境条件以及可测量的响应),然后选择能满足每个场景的 设计策略,并附上成本。参见 references/scenarios-and-priorities.md 和 references/design-strategies.md。

使分析可信的纪律

  • 发现坏味道。 需求摘要存在重复出现的失败模式:模糊的超级形容词、隐藏的假设、无单位或无来源的数字、矛盾的需求。references/brief-smells.md 是这些模版的手册,并给出了看到它们时应提出的问题。
  • 标记每个假设。 当需求摘要沉默而你需要填补空白时,标明它:是 填补空白(信息缺失,你提供了默认值)、解读(有歧义,你选择了一种理解),还是 范围收窄(你故意排除了一些东西)?建立在未标记假设上的估算,不过是穿着西装的猜测。
  • 以能改变架构的问题收尾。 一份好的分析的输出,应包括两个或三个答案会最大程度改变架构的问题。这些应该是接下来与客户对话的重点。
  • 估算的可靠性,取决于其底层的分析。 这就是为什么分析要先行一步:它让你给出的数字是你能够捍卫的。

如何使用本技能

  • 完整分析一份需求摘要 → 运行上述六步流水线。
  • 判断什么是架构显著的 → references/asr-framework.md。
  • 选择并覆盖质量属性 → references/quality-model.md(ISO/IEC 25010)。
  • 编写可测试的质量场景并排序 → references/scenarios-and-priorities.md。
  • 针对质量属性选择设计方法 → references/design-strategies.md。
  • 发现矛盾和不可能的组合 → references/feasibility-check.md。
  • 批判性阅读需求摘要 → references/brief-smells.md。
  • 规划书面交付物 → references/output-template.md。

相关技能