软件工程 |获取需求方面的挑战
先决条件 - 需求获取
引出需求是需求工程过程的第一步。它帮助分析师获得有关问题域的知识，而这些知识又用于生成软件的正式规范。在此过程中遇到了许多问题和挑战。其中一些如下：
- 理解大而复杂的系统需求是困难的——
“大”这个词代表两个方面：- (i) 由于用户众多，在安全性等方面的限制很大。
- (ii) 需要执行的大量功能。
- 未定义的系统边界 –
可能没有定义的一组实施要求。除了重要的功能外，客户可能还会继续添加一些不相关且不必要的功能，从而导致可能超出确定预算的极大实施成本。 - 客户/利益相关者不清楚他们的需求。 –
有时，客户自己可能不确定他们希望在软件中看到的详尽功能列表。当他们对自己的需求有一个非常基本的想法但对实施部分没有太多计划时，这可能会发生。 - 有冲突的要求——
项目的两个不同利益相关者有可能表达了相互矛盾的实施要求。此外，单个利益相关者有时也可能表达两个不兼容的要求。 - 不断变化的要求是另一个问题——
在来自客户的连续采访或评论的情况下，客户可能会表示最初的一组指定要求发生了变化。虽然很容易满足某些要求，但通常很难处理这种不断变化的要求。 - 对系统进行适当的分区以降低复杂性——
项目有时可以分解为小模块或功能，然后由单独的团队处理。通常，更复杂和更大的项目需要更多的分区。需要确保分区不重叠且彼此独立。 - 验证和跟踪要求 –
在开始实施部分之前交叉检查列出的要求非常重要。此外，应该有前向和后向可追溯性。例如，所有实体名称在任何地方都应该相同，即不应出现在不同的地方使用“STUDENT”和“STUDENTS”来指代同一实体的情况。 - 识别关键要求——
确定必须不惜一切代价实现的一组需求非常重要。应优先考虑需求，以便可以以最高优先级首先实施关键需求。 - 解决需求的“待定”部分——
待定要求集包括那些在未来尚未解决的要求。此类要求的数量应尽可能少。 - 适当的文件、适当的会议时间和预算限制——
确保正确的文档是一项固有的挑战，尤其是在需求不断变化的情况下。时间和预算限制也需要仔细和系统地处理。
概括
有许多与需求工程相关的问题，包括定义系统范围的问题，促进受拟议系统影响的各个社区之间的理解的问题，以及解决需求不稳定性的问题。这些问题可能会产生不可持续的需求并取消程序开发，否则，系统的开发将被认为不令人满意或不可接受，维修成本高，或者会发生变化。通过改进服务交付，可以改进需求工程过程，从而改进系统要求和更好的系统。
工程需求可以从推广需求、规范需求、验证需求中推导出来。当前的大多数策略和需求都集中在清晰度上，即服务表示。该报告关注而不是关注提名，规范策略尚未充分解决的工程需求问题。提出了一种解除方法来解决这些问题。
这种新方法旨在结合现有促销策略的好处，同时仔细研究在服务提供过程中开展的活动。这些活动包括事实调查、数据收集、评估和规划、优先排序和整合。就其本身而言，现有的促销策略在这些领域中的一个或多个方面都缺乏