软件需求的三大层次,逐层细化的注意事项

        需求逐层分解和转化是一个持续优化的过程,在这个过程中,我们需要明确软件需求的三大层次,从而帮助项目团队理解组织或客户的高层目标和期望,满足用户的期望和需求,有助于产品的系统设计和开发。

        一、软件需求三大层次

        软件需求包括三大层次:业务需求、用户需求和功能需求(也包括非功能需求)。

        1、业务需求

        业务需求反映了企业或客户对系统、产品高层次的目标要求。这些需求通常来自于项目投资人、购买产品的客户、客户单位的管理人员、市场营销部门或产品策划部门等。

        此需求描述了组织为什么开发一个产品,希望达到的目标和预期期望。

业务需求
业务需求

        2、用户需求

        用户需求反映了用户的目标,用户使用产品必须完成的任务。此需求通常是在问题基础上对用户进行访谈、调查,通过对用户使用场景的需求整理,从而建立用户需求。

        用户需求须体现产品将给用户带来的业务价值,并能够描述了用户能使用产品来做些什么。

        3、功能需求

        功能需求反映了开发人员必须在系统中实现的软件功能,用户利用这些功能来完成任务,满足业务需要。功能需求是需求的主体,它描述的是开发人员如何设计具体的解决方案来实现这些需求,其数量往往比用户需求高一个数量级。

        此需求是从软件系统角度来说明软件的需求,此需求也包括非功能需求。它描述了系统展现给用户的行为和执行的操作等。它包括产品必须遵从的标准、规范和合约;外部界面的具体细节;性能要求;设计或实现的约束条件及质量属性。

        二、层次之间的相互关系

        业务需求是需求定义的产物;用户需求是需求捕获的结果;软件需求是需求分析和建模的综合。这三个层次从整体到局部、从概念到细节逐步细化,帮助团队更好地理解和满足项目的需求。

        需要注意的是,这三个层次并非完全独立,而是相互关联、相互影响的。业务需求提供了系统的目标和背景,用户需求进一步细化了业务需求,而功能需求则是为了满足用户需求和业务需求而提出的具体功能要求。通过逐层递进的方式,可以确保需求的准确性和一致性,从而更好地满足项目的目标和利益相关者的期望。

软件需求三大层级
软件需求三大层级

        另外,业务需求和用户需求只有经过需求分析的转化,变为产品的功能需求后,才能得以实现。

        三、软件需求逐层细化注意事项

        需求的逐层分解和转化是将高层需求逐步细化为更具体、更详细的子需求的过程。这个过程可以帮助团队更好地理解和满足项目的需求,为了保证需求的准确性和一致性,需要遵循以下注意事项:

        1、明确需求来源和需求描述

        首先需要确保需求来源的可靠性,一般来源于利益相关者、用户反馈、业务规则等。并与相关方进行充分的沟通和讨论,将需求以清晰、具体、可测量的方式进行描述。

        使用明确的术语和定义,避免模糊和歧义。确保每个需求都能够被准确理解和解释。

需求来源
需求来源

        2、需求分析和验证

        此过程需与利益相关者和团队成员密切合作,通过讨论、审查和确认,确保需求的准确性和一致性。使用技术工具和方法,如原型设计、模型建立和模拟等,帮助验证需求的可行性和正确性。

        如CoCode开发云使用GPT技术,通过需求条目化和自动分解子需求功能,将用户需求一键自动生成标准用户故事;需求分析工具使用AI通过需求测试和一致性检测,能够在几分钟内快速分析用户需求缺陷,如歧义、重复、遗漏、不一致和复杂性等问题,精准锁定需求问题,从而有助于高效地修改需求缺陷,提高用户需求分析质量。

        3、需求优先级排序和跟踪管理

        对细化后的子需求进行优先级排序,确定哪些需求是最重要和最紧急的。这可以帮助团队在资源有限的情况下做出决策,并确保关键需求得到优先满足。 常见评判需求优先级规则有:四象限法则、KANO模型、二八原则、产品生命周期法、ROI评估法。

        另外需建立一个需求追踪和管理系统,跟踪每个需求的状态、变更和关联关系。确保每个需求都有唯一的标识符,并与其他相关需求进行关联。这样可以更好地管理需求之间的依赖关系和一致性。

需求跟踪和管理
需求跟踪和管理

        4、变更控制和变更管理

        在需求分解和转化过程中,随着需求的变更和演化,需要及时进行变更控制和变更管理,坚持需求变更流程。确保每个需求的变更都经过充分的评估和批准,从而有效避免需求变更对其他需求产生负面影响。

        软件需求分为三大层次,需求逐层分解和转化是一个持续优化的过程,需要不断与利益相关者和团队成员进行沟通和协商。通过有效的需求分析、排序、管理和追踪,从而确保需求的准确性。

  • 1
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
本书讲述了软件开发中一个至关重要的问题—软件需求问题。软件开发人员及用户往往容易忽略信息沟通,导致软件开发出来后,不能很好地满足用户的需要。而返工则不仅在技术上给开发人员带来巨大的麻烦,而且软件性能深受影响且造成人力、物力的浪费。所以在开发周期早期提高项目需求分析的质量,减少重复劳动,通过控制项目范围的扩展及需求变更来达到按计划完成预定目标是当前我国软件业急需解决的问题—这也是本书讨论的主要内容。 目 录 译者序 前言 第一部分 软件需求:是什么和为什么 第1章 基本软件需求 1 1.1 软件需求的定义 2 1.1.1 一些关于“需求”的解释 2 1.1.2 需求层次 3 1.2 每个项目都有需求 4 1.3 什么情况将会导致好的群体发生不合格 的需求说明 5 1.4 高质量的需求过程带来的好处 7 1.5 优秀需求具有的特性 7 1.5.1 需求说明的特征 7 1.5.2 需求规格说明的特点 8 1.6 需求的开发和管理 9 第2章 客户的需求观 11 2.1 谁是客户 12 2.2 客户与开发人员之间的合作关系 12 2.2.1 软件客户需求权利书 13 2.2.2 软件客户需求义务书 15 2..3 “签约”意味着什么 17 第3章 需求工程的推荐方法 18 3.1 知识技能 19 3.2 需求获取 20 3.3 需求分析 21 3.4 需求规格说明 22 3.5 需求验证 23 3.6 需求管理 23 3.7 项目管理 24 第4章 改进需求过程 26 4.1 需求与其他项目过程的联系 26 4.2 软件需求对其他项目风险承担者的影响 27 4.3 软件过程改进的基础 28 4.4 过程改进周期 29 4.4.1 评估当前采用的方法 29 4.4.2 制定改进活动计划 30 4.4.3 建立、实验和实施新的过程 31 4.4.4 评估结果 32 4.5 需求过程的积累材料 33 4.5.1 需求开发过程的积累材料 34 4.5.2 需求管理过程的积累材料 34 4.6 需求过程改进路标 35 第5章 软件需求与风险管理 37 5.1 软件风险管理基础 38 5.1.1 风险管理的要素 38 5.1.2 编写项目风险文档 39 5.1.3 制定风险管理计划 40 5.2 与需求有关的风险 41 5.2.1 需求获取 41 5.2.2 需求分析 42 5.2.3 需求规格说明 42 5.2.4 需求验证 43 5.2.5 需求管理 43 5.3 风险管理是你的好助手 43 第二部分 软件需求工程 第6章 建立项目视图与范围 45 6.1 通过业务需求确定项目视图 45 6.2 项目视图和范围的文档 46 6.3 关联图 50 6.4 把注意力始终集中在项目的范围上 51 第7章 寻找客户的需求 52 7.1 需求的来源 52 7.2 用户类 53 7.3 寻找用户代表 54 7.4 产品的代表者 55 7.4.1 寻求产品代表者 56 7.4.2 产品代表者的期望 56 7.4.3 多个产品代表者 57 7.5 谁作出决策 58 第8章 聆听客户的需求 60 8.1 需求获取的指导方针 60 8.2 基于使用实例的方法 62 8.2.1 使用实例和用法说明 62 8.2.2 确定使用实例并编写使用实例文档 64 8.2.3 使用实例和功能需求 67 8.2.4 使用实例的益处 67 8.2.5 避免使用实例陷阱 68 8.3 对客户输入进行分类 69 8.4 需求获取中的注意事项 70 8.5 如何知道你何时完成需求的获取 71 第9章 编写需求文档 72 9.1 软件需求规格说明 72 9.1.1 标识需求 73 9.1.2 处理不完整性 74 9.1.3 用户界面和软件需求规格说明 74 9.2 软件需求规格说明模板 75 9.3 编写需求文档的原则 79 9.4 需求示例的改进前后 81 9.5 数据字典 83 第10章 需求的图形化分析 85 10.1 需求建模 85 10.2 从客户需求到分析模型 86 10.3 数据流图 87 10.4 实体联系图 88 10.5 状态转换图 90 10.6 对话图 92 10.7 类图 94 10.8 最后的提醒 96 第11章 软件的质量属性 97 11.1 非功能需求 97 11.2 质量属性 97 11.3 定义质量属性 98 11.3.1 对用户重要的属性 99 11.3.2 对开发者重要的属性 100 11.4 属性的取舍 101 第12章 通过原型法减少项目风险 103 12.1 原型是“什么”和“为什么”要原型 103 12.2 水平和垂直的原型 103 12.3 抛弃型原型或进化型原型 104 12.4 书面原型和电子原型 106 12.5 原型评价 107 12.6 原型法的最大风险 108 12.7 原型法成功的因素 108 第13章 设定需求优先级 110 13.1 为什么要设定需求的优先级 110 13.2 不同角色的人处理优先级 111 13.3 设定优先级的规模 111 13.4 基于价值、费用和风险的优先级设定 112 第14章 需求质量验证 116 14.1 需求评审 117 14.1.1 审查过程 118 14.1.2 需求评审的困难 122 14.2 测试需求 124 第15章 需求开发向设计规划的转化 128 15.1 从需求到项目规划 128 15.1.1 需求和进度安排 128 15.1.2 需求和预估 129 15.2 从需求到设计和编码 130 15.3 从需求到测试 131 15.4 从需求到成功 131 第三部分 软件需求管理 第16章 需求管理的原则与实现 133 16.1 需求管理和过程能力成熟度模型 133 16.2 需求管理步骤 135 16.3 需求规格说明的版本控制 135 16.4 需求属性 136 16.5 度量需求管理的效果 138 第17章 管理变更请求 139 17.1 控制项目范围的扩展 139 17.2 变更控制过程 140 17.2.1 变更控制策略 140 17.2.2 变更控制步骤 141 17.2.3 变更控制工具 144 17.3 变更控制委员会 145 17.3.1 变更控制委员会的组成 145 17.3.2 变更控制委员会总则 145 17.4 测量变更活动 146 第18章 需求链中的联系链 149 18.1 需求跟踪 149 18.1.1 需求跟踪动机 151 18.1.2 需求跟踪能力矩阵 151 18.1.3 需求跟踪能力工具 153 18.1.4 需求跟踪能力过程 153 18.1.5 需求跟踪能力可行吗,必要吗? 154 18.2 变更需求代价:影响分析 154 18.2.1 影响分析过程 155 18.2.2 影响分析报告模板 157 第19章 需求管理工具 158 19.1 使用需求管理工具的益处 159 19.2 商业需求管理工具 160 19.3 实现需求管理自动化 161 附录 当前需求实践的自我评估 163 参考文献 167 后记 171
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值