软需---软件需求过程

软件需求过程

可行性研究

可行性研究是一个面向管理的活动，经过可行性研究，管理人员需要做出启动该项目与否的重要决定

可行性研究对象

• 当前组织系统，如用户、规章、功能、目标等

• 当前组织系统中的问题，如功能及性能的不一致，不充分

• 新系统的目标及需求，如有哪些问题需要解决？需要做哪些改变？

• 约束条件，包括系统的非功能性需求

• 可能的候选方案

  • 保持系统当前现状应作为候选方案之一
  • 解决现有问题的各种商业过程应作为候选方案考虑
  • 将对解决方案的不同层次和类型的计算机化应作为候选方案考虑

• 各候选方案的优缺点、特性

可行性研究报告

• 项目的可行性
• 项目的首选方案

可行性研究

• Operational Feasibility 操作可行性
  一个本来能行的解决方案可能因最终用户及管理人员的反对而失败

• Technical Feasibility 技术可行性
  所建议的技术或解决方案是否实用？
  成熟的技术通常有较大的客户群，从中可得到关于其存在的问题和改进的看法和建议
  所需的技术是否可从内部获得？

• Schedule Feasibility 时间可行性

  需要多长时间能够获得所需的专业知识？
  评估时间风险

• Economic Feasibility 经济可行性

  财务底线是否可量化？
  性能价格比分析：

1、补偿分析：项目在多长时间之内会产生回报及额外开销
2、净价值分析：根据新项目的当前市值估算净利润
3、针对各候选方案进行投资回报分析：比较可选解决方案的全寿期收益率

软件需求工程的过程和阶段

决定软件系统开发目标的过程称为软件需求工程过程。

Gathering Requirements 收集需求

• 业务需求
• 用户需求
• 功能需求

Analyzing requirements 分析需求
Creating the SRS document 建立SRS文档
Verifying the Requirements 验证需求
Managing Requirements 管理需求

• 变更控制
• 版本控制
• 需求跟踪
• 需求状态跟踪

软件需求工程的优势

• 把重写、冗余和误解的可能性降到最低。
• 提高系统的可用性和可维护性。
• 能够为准备适当的技术人员提供依据，另外，为经费、时间和设备的预算提供依据。
• 使客户、开发团队和用户就将交付软件的验收准则达成共识。这取决于需求规格说明阶段文档中记录的需求。

需求获取

• 从人、文档或者环境当中获取需求的过程
• 需求获取和需求分析是交织在一起的
• 需求获取是需求工程的核心任务，即确定软件系统风险承担者的需要及限制条件的过程
• 需求获取着重于发现用户需求。用户需求包括用户要求系统完成什么任务和用户对性能、易用性和其他质量属性的期望

需求分析

• 通过建模来整合各种信息，使人们更好的理解问题
• 检查需求中存在的错误、遗漏和不一致并加以改正。
• 分析的目的在于开发出高质量的具体的需求，为项目估算、结构设计和测试提供定量信息
• 需求分析活动最终会产生一个需求基线集，他制定了系统开发需要完成的任务

需求规格说明

• 需求要求简洁、精确、一致和易于理解
• 包含详细的软件的功能需求和非功能需求

需求验证

• 检查规格说明以保证所有系统需求已被无歧义地陈述，不一致性、疏忽和错误已被检查出并纠正，并且工作产品符合过程、项目和产品建立的标准

需求管理

• 保证需求作用的持续、稳定和有效的发挥

风险管理

就是在风险给项目带来损失之前，就指明、评估并对风险加以控制
风险管理就是使用某些工具和步骤把项目风险限制在一个可接受的范围内

风险管理

• 风险评价

  • 标识
  • 分析
  • 确定优先级

• 风险避免

• 风险控制

  • 指定管理计划
  • 解决方案
  • 监控

改进需求过程

解决在以前项目或目前项目中遇到的问题
防止和避免你可能在将来的项目中要遇到的问题

习题