需求分析

在 IT 中，需求分析是系统开发过程的一部分（除其他事项外，还包括需求管理）和业务分析的一部分。 目的是确定、构造和检查客户对要开发的系统的要求。 需求分析的结果通常记录在规范中，或者在敏捷软件开发的情况下，这会导致产品积压。

xxx的组织为需求分析命名了以下组件：

根据IEEE，需求工程可以分为：

• 需求启发，
• 需求分析，
• 需求规范和
• 需求验证

这些活动重叠，并且经常重复进行多次。

卡内基梅隆大学软件工程研究所 (SEI) 在其能力成熟度模型中区分了集成

• 需求的演变和
• 需求管理。

在罗伯逊开发的 Volere 程序模型中存在

• 需求规范，
• 利益相关者分析，
• 需求分析，
• 分析优先级和
• 记录基本要求。

国际商业分析学会 (IIBA) 在商业分析知识体系 (BABOK) 中列出了关于此主题的三个章节：

• 需求获取：确定利益相关者的需求，
• 需求管理 沟通：管理和沟通需求，识别可重复使用的需求，组装需求，准备批准需求，管理需求变更，
• 需求分析：确定需求的优先级和结构，以文本形式记录需求，用图形/模型记录需求，检查内容质量，检查是否符合目标。

国际需求工程委员会 (IREB) 在需求工程认证专家 (CPRE) 认证的教科书中列出了关于此主题的四个章节：

• 发现：需求发现使用多种技术从利益相关者和其他来源提取、细化和优化需求。
• 文档：文档中充分描述了要求。
• 审查和协调：必须在早期阶段审查和协调记录的要求，以确保它们满足所有要求的质量标准。
• 管理：需求管理与所有其他活动一起进行，包括构建需求、为不同角色做好准备以及一致地更改和实施需求所需的所有措施。

在所有上述模型中，以下步骤以一种或另一种形式存在。 需求收集（英文启发）； 通过分析，建立共识； 要求以文本或模型的形式记录， 之后，通常会检查整个事情是否仍然一致（验证）。 围绕这些步骤存在过程的管理和管理。

记录后，需求必须结构化和分类。 这确保了需求变得更加清晰。 这反过来又增加了对需求之间关系的理解。 这里的标准是：

必须检查依赖需求以确定一个需求是否是另一个需求的先决条件，它们是否相互依赖或者它们是否可以独立实现。相关需求在逻辑上和专业上属于一起的不应单独实现。角色相关的每个用户组都有自己对需求的看法，应该支持，看用户角色。

其他结构化选项是功能性和非功能性需求，以及专业动机（专业和技术）和技术动机（仅技术）的需求。 以这种方式构建的需求必须在客户和开发人员之间达成一致。 如有必要，这种协调可以成为一个迭代过程，从而导致需求的细化。

在构建之后，有时与此同时，根据质量特性对需求进行质量保证：

正确的要求必须相互一致。看可行性。必要的，客户没有要求的不是要求。优先考虑的，必须明确哪些要求是最重要的。 确定优先级的目的是先提供经常需要或对客户特别重要的功能，然后再提供不太经常需要的功能。 它是通过量化功能分支来实现的。可用的，有用的，即使是部分实施，也应该已经创建了一个生产系统。

测试结果构成规范的基础，评估有时会相互竞争。 只实现高优先级的任务并不会自动产生一个高效的系统。 评价时，不仅要考虑单个功能本身，还要考虑它在整个系统中的作用。