软件需求定义与管理全解析

### 软件需求定义与管理全解析 在软件开发过程中，准确地定义和管理需求是确保项目成功的关键。本文将深入探讨非功能需求的概述、需求的优先级排序以及功能需求的详细细化等重要环节。 #### 1. 概述非功能需求 非功能需求代表着系统的质量或约束条件，对于架构师而言，识别这些需求尤为重要，因为它们往往是架构设计中最具挑战性的部分。 ##### 1.1 任务目的与角色 - **目的**：概述非功能需求集。 - **角色**：涉及应用架构师（次要）、业务分析师、基础设施架构师（次要）和利益相关者（次要）。 ##### 1.2 输入与输出 - **输入**：业务规则（可选）、企业架构原则（可选）、术语表、利益相关者请求、系统上下文和愿景。 - **输出**：非功能需求。 ##### 1.3 步骤 - **识别非功能需求**：主要基于利益相关者请求工作产品中的请求来推导非功能需求。使用问卷可以使这项工作更轻松，因为请求已经按照与非功能需求工作产品内容相匹配的方式进行了分类。同时，还可以参考业务规则、愿景、系统上下文和企业架构原则等工作产品。例如，YourTour系统的非功能需求包括可访问性、可用性、可扩展性和可测试性等代表质量的需求，以及进度、集成、平台支持、标准合规性和第三方组件等代表约束的需求。 - **概述非功能需求**：以YourTour系统为例，非功能需求工作产品中的类别和需求来自FURPS分类。非功能需求必须使用术语表中定义的术语进行记录，并且要确保可测量，以证明是否满足这些需求。同时，为避免歧义，可以明确说明不需要的内容。 以下是YourTour系统非功能需求工作产品的部分示例： | 类别 | 需求 | 描述 | | --- | --- | --- | | 可用性 | 可访问性 | 系统将根据YourTour组织标准支持有视觉、听觉、运动或认知障碍的人员。 | | 可靠性 | 可用性 | 对于需要安全访问的功能（如预订旅游），系统将提供99.9%的可用性；对于其他功能（如浏览旅游），系统将提供99%的可用性。备份和维护操作不需要系统离线。 | | 性能 | 速度 | 系统将在不到十秒的时间内处理旅游预订确认（包括与MyPay支付引擎和MyReservation预订系统的任何交易）。 | | 可支持性 | 可扩展性 | 系统将支持100,000名注册用户和5,000名并发用户。 | | 可支持性 | 可测试性 | 系统将允许记录任何交易的内容，以便验证所有交易及其有效负载。 | | 业务约束 | 进度 | 系统将在不到六个月的时间内交付。 | | 架构约束 | 通信 | 系统将使用行业标准的Web协议进行互操作性。 | | 架构约束 | 遗留集成 | YourTour系统将使用YourTour现有的CRM系统来存储客户信息。 | | 开发约束 | 平台支持 | YourTour系统将通过支持互联网的设备（如Web浏览器和PDA）提供。 | | 开发约束 | 标准合规性 | YourTour系统将根据YourTour开发标准进行开发。 | | 开发约束 | 第三方组件 | YourTour系统将不直接实现支付和预订（住宿和交通）的处理；它将分别与MyPay支付引擎和MyReservation预订系统进行接口。 | #### 2. 需求优先级排序 需求优先级排序的目的是根据最高优先级的需求来规划迭代，以确保项目能够高效地推进。 ##### 2.1 任务目的与角色 - **目的**：对需求进行优先级排序，以便基于最高优先级的需求规划迭代。 - **角色**：业务分析师、首席架构师、项目经理（次要）和利益相关者（次要）。 ##### 2.2 输入与输出 - **输入**：术语表、功能需求、非功能需求、RAID日志、利益相关者请求和愿景（可选）。 - **输出**：优先级需求列表。 ##### 2.3 步骤 - **优先级排序**：可以通过查看所有功能和非功能需求来进行初始优先级排序，确定当前迭代中应尝试解决的高优先级需求。由于需求并非总是完全独立的，因此在优先级排序时考虑用例和其他需求的对齐情况是有益的。例如，通过一个简单的表格可以展示用例与其他需求的覆