本文更新版本已挪至  

---------------------

描述

　　需求分析描述我们如何逐步详细的定义方案，以便项目团队设计和构建出满足业务和涉众需要的解决方案。

目的

• 逐步细化获取后的需求，在特定范围内更清晰的定义需求
• 验证需求是否满足业务需要
• 测试需求，确认需求高质量

任务

• 组织需求（Organize Requirements）
• 划分优先级（Prioritize Requirements）
• 详述需求和建模（Specify and Model Requirements）
• 确定假定和约束（Determine Assumptions and Constraints）
• 确认需求（Verify Requirements）
• 验证需求（Validate Requirements）

任务：组织需求（Organize Requirements）

• 目的
  　　预计需求的级别，功能的分组等的功能，把需求组织成结构化的逻辑分组。
• 输入
  • 业务案例
  • 方案范围
  • 需求
• 输出
  　　结构化的需求

任务：划分优先级（Prioritize Requirements）

• 目的
  　　决定需求的优先级，标识需求之间的逻辑依赖性
• 输入
  • 需求
  • 业务案例
• 输出
  　　经过划分优先级的需求（Prioritized requirements）

任务：详述需求和建模（Specify and Model Requirements）

• 目的
  • 捕获需求质量属性
  • 使用文字描述需求和通过图形建模
• 输入

  　　需求

• 输出
  　　详细的或者建模后的需求

任务：确定假定和约束（Determine Assumptions and Constraints）

• 目的

  　　在分析涉众需求时，我们会发现他们的期望不是需求，例如经费限制、开发期限、相关行业法律法规等。假设和约束最大的区别就是一个是确定的，一个是不确定的，约束是项目必须遵循的依据。

• 输入

  　　涉众声明（Stakeholder Statements）

• 输出
  　　假定和约束（Assumptions and Constraints）

任务：确认需求（Verify Requirements）

• 目的

  　　检查需求被正确的、完整的定义出来

• 输入

  　　详述或模型化的需求

• 输出
  　　确认后的需求

任务：验证需求（Validate Requirements）

• 目的

  　　验证需求满足业务需要

• 输入

  　　确认后的需求

• 输出
  　　验证后的需求

 

更多内容：

 

欢迎转载，转载请注明：转载自 [ ]