系统需求获取与特征定义全解析

### 系统需求获取与特征定义全解析 #### 需求获取的挑战 在系统开发过程中，从用户和其他利益相关者那里获取需求看似简单，实则困难重重。这一过程之所以复杂，主要是受到三种常见综合征的影响。 ##### 1. “Yes, But” 综合征 在应用开发中，“Yes, But” 综合征是一个令人沮丧且普遍存在的问题。当用户首次看到系统实现时，通常会有两种截然不同的反应：一是觉得系统很棒，能满足需求；二是提出各种疑问和改进建议。 这种综合征的根源在于软件是一种无形的智力过程，用户难以像体验物理设备那样提前感受软件。而且开发团队往往在生产代码完成后才让用户交互和评估，这使得用户在看到实际系统时才发现与预期不符。 相比之下，机械设备的开发过程有完善的原理验证模型、草图、模型等阶段，用户可以在详细实现完成前就与早期设备进行交互。而软件由于其复杂性，却要求一次开发成功。 应对 “Yes, But” 综合征，我们要认识到它是人类本性和应用开发的一部分，应提前规划。可以采用一些技术尽早引出用户的 “But”，让开发精力集中在通过 “Yes, But” 测试的软件上。 ##### 2. “Undiscovered Ruins” 综合征 寻找需求就像寻找未被发现的遗迹，找到的越多，就越知道还有更多未被发现。软件开发团队常常难以确定何时完成需求获取，即何时找到了所有重要需求或足够的需求。 为解决这个问题，我们可以采用多种技术，同时在问题分析阶段识别所有利益相关者，因为很多非用户利益相关者可能持有未被发现的需求。虽然我们知道这是一个无法完全完成的任务，但在某个阶段可以自信地说已经发现了足够的需求，其余的后续再找。 ##### 3. “User and the Developer” 综合征 该综合征源于用户和开发者之间的沟通差距。用户和开发者通常来自不同的世界，有着不同的背景、动机和目标，这使得沟通变得困难。 以下是该综合征的常见问题及解决方案： |问题|解决方案| | ---- | ---- | |用户不知道自己想要什么，或知道但无法表达|认可用户作为领域专家的地位，尝试采用替代的沟通和需求获取技术| |用户以为自己知道想要什么，直到开发者实现后才发现并非如此|尽早提供替代的需求获取技术，如故事板、角色扮演、一次性原型等| |分析师认为自己比用户更了解用户问题|让分析师站在用户的角度，进行一小时或一天的角色扮演| |每个人都认为对方有政治动机|认识到这是人性的一部分，继续推进项目| #### 产品或系统的特征 开发团队很少能拿到完美或合理的系统开发规范，因此需要更积极地获取需求。了解利益相关者和用户的需求对于开发更好的系统至关重要，这些需求为系统的定义和实现提供了关键信息。 ##### 1. 利益相关者和用户需求 利益相关者和用户需求通常比较模糊和不确定，例如 “我需要更简单的方式了解库存状态” 或 “我希望大幅提高销售订单录入的生产率”。我们将利益相关者需求定义为：为了证明考虑、购买或使用新系统的合理性而必须解决的业务、个人或运营问题（或机会）的反映。 ##### 2. 特征 当被询问新系统的需求时，利益相关者通常不会直接描述需求，而是描述介于需求和实际要求之间的抽象内容，我们称之为产品或系统的特征。这些特征是对期望系统行为的高级表达，虽然可能定义不明确且相互冲突，但它们代表了真实的需求。 特征的定义为：系统为满足一个或多个利益相关者需求而提供的服务。通过特征，我们可以方便地描述系统功能，而无需陷入过多细节。 特征通常用自然语言表达，是一个简短的短语。以下是一些特征的示例： |应用领域|特征示例| | ---- | ---- | |电梯控制系统|火灾紧急情况下门的手动控制| |库存控制系统|提供所有库存物品的最新状态| |缺陷跟踪系统|提供趋势数据以评估产品质量| |工资系统|按类别报告到目前为止的扣除额| |家庭照明自动化系统（HOLIS）|长时间外出的假期设置| |武器控制系统|攻击授权至少需要两次独立确认| |盒装应用程序|与 Windows XP 兼容| ##### 3. 管理复杂性 为了管理系统的复杂性，我们建议将系统的功能抽象到足够高的级别，使特征数量控制在 25 - 99 个，少于 50