软件系统需求定义与逻辑架构创建全解析

# 软件系统需求定义与逻辑架构创建全解析 ## 1. 细化非功能需求 ### 1.1 非功能需求细化的目的与角色 细化非功能需求的目的是完善这些需求，使其能够驱动系统定义，涵盖系统展现的特性和需适应的约束条件。参与此任务的角色包括应用架构师（次要）、业务分析师、基础设施架构师（次要）和利益相关者（次要）。在当前迭代中，需针对高优先级项目的非功能需求进行细化，过程中可能会遇到未明确表述的需求或需对现有需求进行根本性修改的情况，这些改进可在当前或下一次迭代中完成。 ### 1.2 输入与输出 输入包括词汇表（可选）、非功能需求、优先级需求列表和利益相关者请求；输出为细化后的非功能需求。 ### 1.3 具体步骤 #### 1.3.1 细化非功能需求 此步骤旨在为相关非功能需求补充必要细节。例如，“系统将具备可扩展性”这一需求，若不明确用户数量、数据量等具体含义，就无法有效处理该需求。支持 100,000 个并发用户的可扩展解决方案与支持 100 个并发用户的方案可能截然不同。为补充非功能需求描述，可运用 SMART 原则，即具体（Specific）、可衡量（Measurable）、可实现（Achievable）、现实（Realistic）和有时限（Time-based）。每个非功能需求的描述还应参考词汇表，确保术语一致，必要时可参考利益相关者请求以理解需求意图。 #### 1.3.2 细化非功能需求场景 非功能需求场景的细化主要关注系统质量。每个场景包含六个部分： - **刺激因素（Stimulus）**：定义系统必须处理的条件。 - **刺激源（Source of the stimulus）**：定义引发场景启动的角色、系统或系统元素。 - **受刺激的工件（Artifact stimulated）**：代表刺激的目标，即系统或系统的一部分。 - **环境（Environment）**：定义刺激发生的条件。 - **响应（Response）**：代表系统在特定环境条件下对刺激的响应。 - **响应度量（Response Measure）**：定义如何处理结果。 以可扩展性场景为例： |场景部分|详情| | ---- | ---- | |刺激因素|旅游预订的发起| |刺激源|在 YourTour 系统发起预订的最终用户| |受刺激的工件|YourTour 系统| |环境|当前有 5,000 个并发用户登录系统| |响应|由于达到阈值，预订请求被拒绝（假设定义的并发用户限制为 5,000）| |响应度量|发起旅游预订的最终用户会收到通知，被告知当前无法预订旅游，并被告知应采取的行动| 这种描述方式比简单陈述“系统必须支持 5,000 个并发用户扩展”更明确和可衡量。 ### 1.4 架构师的角色 架构师需确保所有非功能需求以恰当方式描述，并协助细化具体场景。 ## 2. 更新软件架构文档 ### 2.1 目的与角色 更新软件架构文档的目的是记录对架构有重要意义的需求，此任务由首席架构师负责。软件架构文档的需求视图用于记录这些重要需求，同时多个交叉视图可帮助描述特定关注点的需求。 ### 2.2 输入与输出 输入包括业务流程模型、功能需求、词汇表、非功能需求、RAID 日志、利益相关者请求和系统上下文；输出为更新后的软件架构文档。 ### 2.3 具体步骤 更新软件架构文档的需求视图和任何交叉视图，该需求视图包含对架构有重要意义的功能和非功能需求。要牢记软件架构文档的目的是便于架构的沟通，从需求角度看，需传达对架构有重大影响的需求以及架构设计的理由，这在架构评审时尤为重要。 ### 2.4 架构师的角色 架构师负责此任务，确保文档准确记录架构需求。 ## 3. 与利益相关者评审需求 ### 3.1 目的与角色 与利益相关者评审需求的目的是获得他们的认可，确保当前细化程度的需求能满足其请求。参与角色包括应用架构师（次要）、业务分析师、数据架构师（次要）、基础设施架构师（次要）、首席架构师和利益相关者。 ### 3.2 输入与输出 输入包括业务实体模型、业务流程模型、业务规则、企业架构原则、现有 IT 环境、功能需求、词汇表、非功能需求、优先级需求列表、RAID 日志、软件架构文档、利益相关者请求、系统上下文和愿景；输出包括变更请求