软件工程中的需求分析流程

本文是对IEEE-29148 系统与软件工程-生命周期流程-需求工程的第六章的整理和解读,在原文基础上有做适当润色调整。全文分为五个部分,分别是:

  • [需求工程流程 1概述](https://srs.pub/specification/req-flow-guide.html)
  • [利益相关者 2需求定义流程](https://srs.pub/specification/req-flow-strs.html)
  • 需求分析流程
  • [需求工程活动 3](https://srs.pub/specification/req-flow-activity.html)
  • [需求管理 4](https://srs.pub/specification/req-flow-management.html)

本文是第三部分:需求分析流程

目的

需求分析流程的目的是将利益相关者对所需服务的需求驱动视图转化为可以提供这些服务的所需产品的技术视图。此流程构建了未来系统的表示,该系统将满足利益相关者的要求,并且在约束允许的范围内,并不意味着任何特定的实现。它会产生可衡量的系统要求,从供应商 5的角度来看,这些要求指定了系统需要具备哪些特性以及在多大程度上才能满足利益相关者的要求。

结果

成功实施需求分析流程的结果是:

  • 产品所需的特性、属性以及功能和性能要求解决方案已指定。
  • 指定影响系统架构设计的约束及其实现方法。
  • 实现系统需求与利益相关者需求的完整性和可追溯性。
  • 定义验证系统要求是否得到满足的基础。

活动和任务

项目应根据与需求分析流程相关的适用组织政策和程序实施以下活动和任务。

定义系统要求

此活动包括以下任务:

  1. 根据要提供的行为和属性定义系统的功能边界。
    注:这包括系统的刺激及其对用户和环境行为的响应,以及对系统与其操作环境之间所需交互的分析和描述,这些交互包括界面约束,如机械、电气、质量、热、数据和程序流。这确定了在其边界上以定量形式表达的预期系统行为。

    在定义系统需求之前,可以通过与利益相关者建立系统(或服务)的边界条件来最大限度地减少范围问题。影响边界条件的三个因素是:组织、环境和约束。

  2. 定义系统需要执行的每个功能。
    注 1:这包括系统(包括其操作员)执行该功能的要求有多高、系统能够执行该功能的条件、系统开始执行该功能的条件以及系统停止执行该功能的条件。

    注 2:功能执行条件可能包括对系统所需状态和操作模式的参考。系统需求在很大程度上取决于拟议系统特性的抽象表示,并可能采用多种建模技术和视角来对所需的系统需求提供足够完整的描述。

随着对系统各个功能和元素之间的相互作用和接口的理解不断加深,需求是通过性能和有效性分析、权衡研究、设计开发、接口定义和成本/收益评估的结合而产生的。同样,对于系统而言,识别和评估重用先前存在的需求的机会非常重要。这包括识别提供类似功能或能力的现有系统、适用于新系统的特定功能或能力以及可重用程度的信息。

注:有关需求重用的更多指导,请参阅 ISO/IEC 26551,软件和系统工程 ‐ 产品线需求工程和管理的工具和方法。

  1. 定义由利益相关者的要求引入的或不可避免的解决方案限制的必要实施约束。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

reddishz

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值