建立风险管理的流程和责任

记录初始已知风险

项目经理应优先考虑风险

2.系统分析和需求定义：

此步骤对于清楚了解客户期望和需求非常重要。因此，非常谨慎地执行此阶段并给予适当的时间是非常重要的，因为任何可能的错误都将导致整个过程的失败。以下是在此阶段进行的一系列步骤：

最终用户要求通过文档，客户访谈，观察和问卷调查获得

确定现行制度的利弊，以避免利弊，推进新制度的利弊。

任何特定的用户提议都用于准备规范，并找到解决第二步中发现的缺点的解决方案。

通常，此步骤涉及以下风险管理活动。

风险管理活动的支持 -

确定需要保护的资产，并在机密性，完整性和可用性方面分配其关键性

识别这些资产的威胁和由此产生的风险

确定现有的安全控制以降低风险

简而言之，我们可以将这个阶段分为五个子阶段：可行性研究，需求获取，需求分析，需求验证，需求文档。

我们将在一些细节中讨论这些阶段，以及这些子阶段涉及的风险因素。

可行性研究 -这是第一个也是最重要的阶段。这个阶段通常作为大项目的独立阶段进行，而不是作为需求定义阶段的子阶段。此阶段允许团队估算特定项目的主要风险因素成本和时间。您可能想知道为什么这么重要？可行性研究有助于我们了解是否值得构建系统。它有助于确定主要风险因素。

风险因素 -

以下是可行性研究阶段的风险因素列表：

项目经理在估算项目的成本，时间，资源和范围时经常会犯错误。不切实际的预算，时间，资源不足和范围不明确经常导致项目失败。

不切实际的预算：如上所述，对预算的不准确估计可能导致项目在SDLC早期耗尽资金。准确的估算预算与正确的时间，精力和资源知识直接相关。

不切实际的时间表：不正确的时间估算会导致项目经理按时交付项目给开发人员带来负担。从而损害了项目的整体质量，从而降低了系统的安全性和脆弱性。

资源不足：在某些情况下，技术，可用工具不是最新的，以满足项目要求或可用的资源（人员，工具，技术）不足以完成项目。无论如何，项目将会延迟，或者在最坏的情况下，它可能导致项目失败。

项目范围不明确：清楚地了解项目应该做什么，哪些功能很重要，哪些功能是强制性的，哪些功能可以被视为额外功能对项目经理来说非常重要。对系统的了解不足可能导致项目失败。

需求启发 -从分析应用程序域开始。这一阶段需要不同利益相关方的参与，以确保有效，正确和完整地收集系统服务，其性能和约束。然后对该数据集进行审查和阐述，以便为下一阶段做好准备。

风险因素 -

不完整的要求：在60％的情况下，用户无法在开始时说明所有要求。因此，要求在完整的SDLC流程中具有最动态的特性。如果未满足任何用户需求，约束或其他功能/非功能要求，则称需求集不完整。

不准确的要求：如果要求集不能反映真实的用户需求，那么在这种情况下要求被认为是不准确的。

要求不明确：通常在SDLC过程中，用户和开发人员之间存在沟通差距。这最终会影响需求集。如果分析师和开发人员无法理解用户提出的要求，则说这些要求不清楚。

忽略非功能性需求：有时开发人员和分析师忽略了非功能性需求与功能需求同等重要的事实。在这种混乱中，他们专注于提供系统应该做什么，而不是系统应该如何像scalabilty，可维护性，可测试性等。

用户需求冲突：系统中的多个用户可能有不同的要求。如果未仔细列出和分析，可能会导致要求不一致。

镀金：在开始时列出所有要求非常重要。在开发期间稍后添加需求可能会导致系统中的威胁。镀金只不过是为系统添加额外的功能而不是之前考虑过的。从而引发威胁并使系统易受攻击。

对实际操作环境的描述不清楚：对实际操作环境的了解不足会导致某些错过的漏洞，因此在软件开发生命周期的后期阶段，威胁仍未被发现。

需求分析活动 -在此步骤中，通过访谈用户或头脑风暴或其他方式收集的要求将是：首先进行分析，然后进行分类和组织，如功能和非功能需求组，然后优先考虑这些需求以更好地了解哪些要求是高度优先的，需要在系统中明确存在。在完成所有这些步骤后，需要协商要求。

风险因素 -

此步骤中的风险管理有以下任务：

不可验证的要求：如果没有可用的有限成本效益的过程（如测试，检查等）来检查软件是否满足要求，那么该要求被认为是不可验证的。

不可行的要求：如果没有足够的资源来成功实施该要求，则认为这是不可行的要求。

不一致的要求：如果要求与任何其他要求相矛盾，那么该要求被认为是不一致的。

不可追踪的要求：每个要求都有一个原始来源非常重要。在记录期间，有必要编写每个需求的原始来源，以便将来可以追溯到需要时。

不切实际的要求：如果要求符合上述所有标准，例如完整，准确，一致，可追溯，可验证等，则该要求足够现实，可以记录和实施。

需求验证活动 -这涉及验证到目前为止收集和分析的需求，以检查它们是否确实从系统中定义了用户想要的内容。

风险因素 -

误解了特定于域的术语：开发人员和应用程序专家经常使用特定于域的术语，或者我们可以说大多数最终用户无法理解的技术术语。从而在最终用户和开发人员之间造成误解。

使用自然语言表达要求：自然语言并不总是表达要求的最佳方式，因为不同的用户可能有不同的标志和惯例。因此，建议使用正式语言进行表达和记录。

要求文档活动 -此步骤涉及通过使用正式语言写下所有商定的要求来创建需求文档（RD）。RD作为不同利益相关者之间的沟通手段。

风险因素 -

不一致的需求数据和RD：有时可能会发生，由于收集和文档处理过程中的故障，实际需求可能与记录的需求不同。

不可修改的RD：如果在RD准备期间，不考虑具有可维护性的RD的结构化，则在变更过程中编辑文档而不重写它将变得困难。