2、软件需求演进概述

软件需求演进概述

1. 引言

如今，大多数软件系统需在不断变化的环境中运行。采用敏捷方法开发的软件，通常会先发布部分完成的版本，因为软件运行的环境和实现都是部分已知的，而驱动软件实现的关键就是需求，它可以通过用户故事、用例或正式规范来表示。

关注软件演进，就必须理解软件的目标，而这些目标本身也在不断变化。期望系统需求恒定不变是不现实的，“前期大设计”方法在强调速度和适应变化的商业环境中已不可取。然而，只关注实现问题而忽略系统目标和业务需求同样不可取。

有三个主要观点反对在软件演进研究中突出需求的重要性：
1. 研究难度 ：具体的实现更容易研究。在很多短期或小范围项目中，需求要么未被明确使用，要么在完成时就已过时。但对于高价值软件产品，这种情况很少见，否则往往意味着软件过程或组织存在问题。
2. 任务数量 ：从数量上看，许多变更任务是低层次的纠错维护，而非高层次的演进任务。虽然纠错任务数量可能更多，但演进性需求变更更复杂、成本更高，因此更重要。
3. 问题域属性 ：需求及其变更被视为问题域的一部分，难以触及，就像理解组织目标一样。但我们认为，重新审视问题域并从问题过渡到解决方案，在软件开发中至关重要。

我们认为需求工件应驱动实现决策，需求必须切实且相关。理想情况下，需求应是结构良好的图，能代表需求问题的各个方面，包括利益相关者目标、领域假设和实现选项。这种模型有助于进行轻量级推理，关键挑战在于“需求修复”，即重新评估可用解决方案以满足变更后的需求，并在必要时添加最少的新实现。

2. 需求相关问题定义