Conditions & Constraints 发现启发¶
本页帮助 Solution Outline（SO）参与者在讨论 Solution Vision 和场景时，发现并表达可能影响 Solution 主张的条件与约束。以下启发按需使用，不是必答清单或评估方法。可以从遇到的线索进入相应分组，也可提出分组之外的问题；有些场景没有特别的条件与约束。
提问索引¶
先想想可能影响 Solution 主张的方面，再查看对应的问题：
- 工作地点、实际环境、设备、连接或跨地区工作 → Location & Environment
- 信息敏感性、安全边界或适用义务 → Security & Regulatory
- 服务或依赖不可用、延迟、中断或恢复 → Availability & Resilience
- 响应时间、处理量、峰值、批次或增长 → Performance & Scalability
- 成本、期限、资源或其他硬限制 → 通用约束
这些方向用于帮助找到可追问之处，不构成完整分类。可只用相关分组，也可从访谈或场景分析中提出其他问题。
Location & Environment¶
- 工作实际发生在哪里？地点、环境或工作方式会改变用户完成目标行动的方式吗？
- 用户可用什么设备或 Client？它们是否适合当前的工作姿态、移动方式、节奏和注意力条件？
- 如果网络或关键依赖不可用，哪些行动可以暂停，哪些必须继续？
- 跨地区工作会改变访问或工作方式吗？是否有人提出了信息处理地点要求？区分用户所在位置与数据处理、存储或部署地点；不要由前者直接推断后者。
Security & Regulatory¶
- Solution 会接触哪些类型的信息？是否涉及敏感信息或组织内的信息分级？
- 相关地区、行业、信息或业务活动可能涉及哪些法规、监管要求或行业标准？谁能确认其适用性？
- 是否有要求限制信息的访问、使用、处理、传输或留存？不确定时，记录待确认的义务和责任方，不在 SO 阶段判断控制是否充分或风险是否可接受。
Availability & Resilience¶
- 哪些行动或结果依赖服务、人员、信息来源或其他系统持续可用？
- 如果关键依赖不可用、响应延迟或工作中断，哪些工作可以等待，哪些必须继续、改用其他方式或停止？
- 用户或业务可以接受什么样的延迟、降级或中断？如果目前不清楚，记录为待确认事项。
这些问题帮助说明业务需要和影响，不要求在 SO 阶段设计恢复架构、服务等级或详细连续性方案。
Performance & Scalability¶
- 哪些响应时间、处理量、并发、峰值或批处理窗口可能影响目标行动或结果？
- 如果用户、交易量、数据量或业务范围增长，当前 Solution 主张中哪些表现可能受影响？
- 是否已有相关的业务期望或限制？若有，记录来源；若没有，不必先估算容量或承诺指标。
通用约束¶
成本、时间与资源等约束与上述发现方向分开记录；不必为了归类而把它们放进技术类别。
- 是否有预算、成本、许可、供应商配额或采购方面的限制？
- 是否有固定期限、业务窗口、季节性、批次截止点或等待成本？
- 是否受人员、技能、支持能力、资源上限、既有平台、组织规则或变更窗口限制？
- 哪些是明确的硬边界，哪些只是当前假设或偏好？来源或确认责任方是什么？
判断是否值得记录¶
对上述四组发现方向和通用约束，都可以问：如果这项条件无法满足，是否可能造成严重后果、妨碍目标行动或改变预期结果？这是帮助判断优先级的重要线索，不是唯一筛选标准。明确的强制义务或硬约束，即使后果暂不清楚，也应记录并标明待确认；未知后果不能被当作没有影响。成本、时间和资源约束同样适用：若超出约束会显著改变方案范围、能否开展或投入时机，应作为重要限制记录；Discovery 阶段只确认方向性影响，不做详细估算或审批。
在 SO 的相关记录中，写明候选条件或约束、它影响的场景或 Solution 主张、已知来源或依据，以及仍然未知的部分。只记录与当前主张相关的内容，不推断未经确认的影响，也不把可能条件直接变成设计要求。
Integrated Assessment（IA）再根据证据判断这些条件对 Solution 的影响、需要进一步调查什么，以及由谁跟进。条件可能触发哪些评估调查，可参照 IA 中 Conditions & Constraints 的调查线索。此处不设状态、评分或路由标签，也不另建一份条件评估台账。