需求工程-软件建模与分析（第3版）课件 第1-9章 需求工程导论- 基于用例场景模型开发用户需求

第一章：需求工程导论2026/9/8目录需求与需求处理软件工程的动机和出发点软件工程需要专门的需求处理软件需求技术的发展什么是需求工程以及为什么需要需求工程？什么时机执行需求工程？谁负责执行需求工程？如何执行软件需求工程？软件需求的人工智能处理方法需求工程与产品工程目录软件工程的动机和出发点工程的通常定义应用科学方法，以成本效益比有效的方式，建造机器，解决现实世界问题。依照工程通常定义的软件工程应用计算科学方法，以成本效益比有效的方式，开发软件系统，解决现实世界问题。软件工程的动机和出发点解决现实世界问题软件需求需求与需求处理软件工程的动机和出发点软件需求是软件工程的动机和出发点需求与需求处理需求软件由于不可抗力的影响，患者希望能够在家中接受医疗咨询、诊断和治疗，而不必前往医院。随着远程工作普及，企业需要有效的协作工具来支持团队沟通和项目管理，确保员工在不同地点也能高效合作。远程医疗平台企业协作工具软件工程需要专门的需求处理其他工程的需求受限而明确的老问题内燃机的工作原理已经被充分研究，热效率、燃油喷射、燃烧过程等关键点都有明确的设计标准。优化参数如活塞行程、燃烧室体积、进气排气系统等都是基于长期的实验和理论研究桥梁设计中的负载、材料强度、风压、地震作用等问题都有成熟的理论和规范。标准化的钢筋混凝土设计、常用的桥梁设计模型和公式，帮助工程师计算出桥梁的承重能力电气工程主要需要考虑的是负荷预测、电源布局、输电网络设计、配电系统设计、电力质量管理等。这些问题目前都已经拥有较为成熟的设计方案和测试方法，在经过一定的学习后，工程师可以很方便地完成这些任务需求与需求处理软件工程需要专门的需求处理软件工程的需求问题新颖基于大语言模型的各种应用无人驾驶技术的各种应用海量数据的处理和推荐算法范围广泛金融、医疗、通讯、教育、环境、工业制造……起始模糊要解决的问题模糊不清全新概念的接触无法确定最大效应的运营方案需求与需求处理美团智能调度系统软件工程需要专门的需求处理软件工程的需求案例需求与需求处理实时调度与多变量需求外卖高峰时段，美团的智能调度系统需要处理数以百万计的订单，并根据实时路况、骑手位置、天气状况等因素，合理分配订单，确保准时送达。用户体验与骑手体验平衡美团不仅要满足用户对准时送达的需求，还需要确保骑手的配送路线合理，避免过度工作。这对需求管理提出了平衡不同群体需求的挑战。个性化需求与实时反馈每个用户的兴趣偏好不同，推荐系统需要根据用户的实时行为进行个性化内容推荐，同时能够快速响应用户的偏好变化，这要求推荐算法具备高度的灵活性和实时性。海量数据处理需求

每天要处理数以亿计的用户请求，推荐系统不仅要从海量内容中筛选合适的内容，还要实时更新用户偏好模型，以提高推荐的准确性和相关性。字节跳动推荐算法软件工程需要专门的需求处理专门的软件需求处理技术主体软件工程师问题的认知源头客户和用户目的快速认知问题建立清晰理解需求与需求处理软件需求技术的发展需求技术随软件工程的发展而发展需求与需求处理机器为中心科学计算1950’s无需求分析应用为中心批量数据处理事务计算1960’s草图分析结构化程序应用功能分解层次式模块1970’s结构化分析DFD、ERD企业为中心的应用企业内部的局域网业务1990’s面向对象分析UML大规模Web应用局域网之间的业务交流与管理2000’s软件需求工程面向大众消费市场的移动应用需求创新快速迭代市场竞争商业模式创新2010’s产品工程目录需求与需求处理什么是需求工程以及为什么需要需求工程？什么是需求工程软件生产中的需求问题软件需求问题的原因分析为什么会感觉不到软件需求工程的重要性什么时机执行需求工程？谁负责执行需求工程？如何执行软件需求工程？软件需求的人工智能处理方法需求工程与产品工程目录需求工程是软件工程的一个分支，它关注于：什么是需求工程软件系统所应予实现的现实世界目标、软件系统的功能和软件系统应当遵守的约束。以上因素和软件行为规格说明之间的联系。以上因素随时间的演化情况。软件工程：（1）应用系统的、规范的、可量化的方法来开发、运行和维护软件，即将工程应用于软件（2）对（1）中各种方法的研究什么是需求工程软件需求工程是所有需求处理活动的总和，它收集信息、分析问题、整合观点、记录需求并验证其正确性，它的目标是让软件能够与应用环境之间建立期望的互动效果。什么是需求工程需求工程目标软件应用环境

需求工程的三个主要任务要同时说明软件“为什么”被需要和需要“做什么”。将目标、功能和约束反映到软件系统中，映射为可行的软件行为，并对软件行为进行准确的规格说明。处理目标、功能和约束随着时间的演化情况。什么是需求工程说明软件系统的建设目标及其应用环境。说明用来达成这些目标的软件功能。说明在设计和实现这些功能时上下文环境对软件完成任务所用方式、方法施加的限制和约束。什么是需求工程同时说明软件“为什么”被需要和需要“做什么”

需求工程的三个主要任务

——任务一需求工程的三个主要任务——任务二什么是需求工程软件需求工程必须将目标、功能和约束反映到软件系统中，映射为可行的软件行为，并对软件行为进行准确的规格说明。软件需求规格说明是软件需求工程最为重要的成果，是项目规划、设计、测试、用户手册编写等很多后继软件开发阶段的工作基础。需求工程的三个主要任务——任务三什么是需求工程现实世界是不断变化的，因此软件需求工程还需要妥善处理目标、功能和约束随着时间的演化情况。处理目标、功能和约束随着时间的演化情况AsTimeGoesBy软件生产中的需求问题软件需求相关的因素为软件项目所带来的风险和问题已经超过了所有的其他因素。为什么需要需求工程长期以来，软件项目的成功率一直都不太理想。虽然新的方法技术层出不穷，解决了很多软件生产难题，但是软件的持续发展也一直在拓展新的领域，遭遇新的问题。

StandishGroup

StandishGroup是各类实践调查数据中最有代表性的一个，它从1995年起长期跟踪软件生产，并定期发布数据报告。为什么需要需求工程StandishGroup将软件项目的结果分为三种成功项目：在预计的时间之内，在预算的成本之下，完成预期的所有功能问题项目：已经完成，软件产品能够正常工作，但在生产中或者超支，或者超期，或者实现的功能不全

失败项目：因无法进行而被中途撤销，或者最终产品无法提交

使用为什么需要需求工程

项目结果数据通过数据分析可以发现，与传统工程项目相比，软件项目的成功率相当不理想，存在着非常大的风险和问题。影响软件生产成功率的最大因素是软件需求问题StandishGroup的软件项目结果数据软件需求问题的原因分析过度关注技术性内容，对非技术性和社会性因素重视不足。传统需求分析方法有缺陷，它忽略了理解现实的需要。软件规模日益扩大，使得需求处理的难度日益凸显。需求问题的高代价性。为什么需要需求工程需求问题的技术原因分析为什么需要需求工程软件工程师们一直将需求建模与分析作为软件需求处理的绝对核心活动。忽略了软件系统和现实之间的互动效应。软件系统环境的组织机构文化、社会背景和系统涉众的目标与利益比软件内部的数据流与状态更应该得到重视。忽略了解决方案和具体应用环境相关性。不能忽视具体应用环境中的相关因素，例如组织机构的文化、组织结构的规范、组织的行业规范、组织的社会背景等等。单纯通过技术的运用来建立一个一致、完整的需求模型是不太可能的。

面对冲突要能够分析社会原因和组织机构方面的原因，引导涉众进行利益协商。非技术性因素：组织机构文化、社会背景、商业目标、利益协商等传统需求分析方法有缺陷结构化分析和面向对象分析具有一定的先天缺陷传统需求分析方法应用路径为什么需要需求工程编程领域设计领域分析领域设计和编程都有构建高质量（健壮性、可维护性、适应性等等）软件的共同目标，而且使用相同的概念和组织机制保证了从设计到编程的平滑过渡。传统的结构化方法和面向对象方法都是最先在编程领域取得成功的。需求分析除了拥有构建高质量软件的目标之外，还有一个更加重要的目标是理解现实。取得成功取得成功具有先天缺陷软件规模日益扩大——以简单任务为应用领域为什么需要需求工程应用范围相对局限在某个部门、某个角色、甚至某个人的任务范围之内。涉及非技术性因素相对较少组织机构文化、社会背景、商业目标、利益协商等。需求来源有限需求相对较为完整和一致，可理解性相对较好。对需求分析人员对要求进行技术分析时对“为什么做”进行描述的要求不是非常必要。软件规模日益扩大——以“企业”为中心应用范围包括企业的各个主要职能部门，包括各部门的主要任务和它们之间任务的协同涉及非技术性因素相对较多涉众会更加广泛，相互之间的利益冲突也会加剧，因此对商业目标和利益协商的处理要求也变得很有必要需求来源广泛需要分析人员将所有用户的理解连接起来，构成全局理解，导出需求对需求分析人员的要求需求分析对规格说明可理解性的要求加强，对“为什么做”进行描述非常重要为什么需要需求工程需求问题的高代价性需求错误的修复代价对比为什么需要需求工程统计表明在需求阶段发生的错误，如果到了维护阶段才发现，则在维护阶段进行修复的代价可以高达需求阶段修复代价的１００～２００倍为什么会感觉不到软件需求工程的重要性？为什么需要需求工程很多情况下，人们会忽略软件需求工程。因为有些特定的问题掩盖了软件需求工程的重要性。问题广为人知问题小而简单像电梯调度、图书管理等。面对此类问题时，不需要使用软件需求工程方法，开发人员也能得到对问题的准确和全面理解，进而开发出符合要求的系统。它们开发的代价较小，因此修复的代价也较小，即使全部推倒重来也不会有太大的影响，因此该类问题可以不采用需求工程的方法。这些特定问题会在一定场合掩盖软件需求处理的必要性。目录需求与需求处理什么是需求工程以及为什么需要需求工程？什么时机执行需求工程？系统工程、软件工程与需求工程需求工程对其他软件开发活动的影响谁负责执行需求工程？如何执行软件需求工程？软件需求的人工智能处理方法需求工程与产品工程目录系统工程、软件工程与需求工程系统工程是一个全局性的过程，它涉及到整个系统的生命周期管理。系统工程在需求工程和软件工程之前开始，它涉及对现实世界中的系统进行设计和改进，以提高系统的整体性能和效率。需求工程是系统工程的一个子集，需求工程通常在系统工程的前期阶段进行，专注于识别、分析和记录系统或软件项目的需求。软件工程也是系统工程的子集，专注于软件部分的开发。它通常在需求工程之后开始（软件工程的某些部分可能在需求工程完全结束之前就开始了），因为只有当需求被明确之后，软件的设计和实现才能开始。2026/9/827什么时机执行需求工程需求工程软件工程系统工程时间线需求工程在系统工程中的位置2026/9/828什么时机执行需求工程需求工程系统需求开发——主要目的是获得整个系统的期望目标——系统需求开发的结果会写入系统需求规格说明——系统需求开发阶段获得的需求被分配到软件工程、硬件工程或 人力工程部分软件需求开发——对软件工程的需求进行更细致的处理——用来确定系统需求中应该由软件满足的部分，将其映射为软件 行为，产生软件需求规格说明总结来说，需求工程包括系统需求开发和软件需求开发两个活动，处于系统工程的起始阶段，部分（系统研究）工作早于软件项目的启动，部分工作属于软件项目的早期阶段。什么时机执行需求工程在1990s中期之后，系统需求开发被称为需求工程的前期阶段(EarlyPhase)。软件需求开发被称为需求工程的后期阶段（LatePhase）。EarlyPhase主要是1990s中期之后发展成熟的。偏向于对现实世界的理解。明确要解决的问题及解决方案、相关涉众、系统特性等。LatePhase传统意义上的需求分析。偏向软件系统的功能定义。使用面向对象分析或结构化分析方法，编制软件需求规格说明。什么时机执行需求工程需求工程对其他软件开发活动的影响需求工程阶段的质量直接影响整个软件开发过程因为其结果即软件需求规格说明书，是后续开发的基础。若需求规格说明书存在错误，将导致后续开发活动出现偏差。在需求开发过程中，会产生诸如前景定义、涉众描述、分析模型和需求特征描述等正性中间产物。这些产物虽然对生成需求规格本身的作用不大，但对其他软件工程活动具有显著的辅助作用。什么时机执行需求工程所以需求工程师的任务对于整个软件开发团队的工作流程至关重要，他们的工作能够确保团队的工作更加顺利进行。需求工程过程对后续软件开发工作的影响示意什么时机执行需求工程需求工程过程对软件开发的影响效果及路径什么时机执行需求工程需求工程收效具体操作影响趋向提高生产率问题理解↑交流沟通过度沟通有效的沟通↓↑开发者的非正式决策↑返工↓提高质量运营支持需求↓交付后缺陷↓提高风险管理估算改进50%特征覆盖率↑需求蔓延↓项目协商↑目录需求与需求处理什么是需求工程以及为什么需要需求工程？什么时机执行需求工程？谁负责执行需求工程？需求工程师需求工程师的技能要求需求工程师的“软技能”需求开发是团队行为如何执行软件需求工程？软件需求的人工智能处理方法需求工程与产品工程目录需求工程师衔接现实世界和计算机世界，涉众与开发者之间的桥梁面对涉众时，需求工程师是软件开发者的代理，负责设计软件解决方案满足涉众的各项要求；面对开发者时，需求工程师是涉众的代理，准确地将各项需求告知开发者。虽然需求工程师自身属于开发者的一个部分，但是需求工程师更应该扮演好涉众代理的角色，站在涉众的立场想问题，替涉众跟踪和监控软件开发过程，保护涉众的利益。谁负责执行需求工程需求工程师谁负责执行需求工程需求工程师的桥梁作用需求工程师的技能要求熟练掌握软件开发方法与技术，保证软件解决方案可行且成本效益比有效非常精确的表达能力，尤其是文档化能力非常好的沟通技能以了解涉众想法，抽象建模与分析能力以准确定义涉众的想法谁负责执行需求工程需求工程师分类模型需求工程师的“软技能”需求工程具有连接现实世界的特殊性，这要求需求工程师有很强的非技术能力，即软技能，涉及认知心理学、社会学、语言学、人类学等人文学科知识:语言交流观察抽象分析与问题解决（抽象、整合、系统化）写作关系协调和团队工作创新（构思更好的软件方案、洞察潜在需求）谁负责执行需求工程需求开发是团队行为需求工程的复杂性使得一个人很难单独完成复杂系统的需求开发工作，所以实践中需求开发往往是团队行为。组建需求团队的注意事项：技能分布：互补且完备交流与沟通技巧团队规模：根据项目规模，2人（一个来自客户；一个需求工程师来自开发者）至数十人客户参与：团队中存在客户方有决策权的人更加有利团队培训：进行必要的培训，尤其是初次参与的成员核心团队：慎重选择需求工程师谁负责执行需求工程市交委认为，手机打车软件部分功能存在安全隐患并违反相关规定，影响了出租车行业运价体系和营运秩序，交通主管部门将依法进行监管和规范。出租车企业负责人表示由于打车软件功能设置和技术运用不够成熟，给行业监管带来了问题，如驾驶员注册准入缺乏认证、提供加价议价功能、操作方式存在行车安全隐患、投诉争议处理困难等，影响了出租车行业运价体系和营运秩序。谁负责执行需求工程案例分析：法律法规与利益协商2013年05月23日

11:03

深圳特区报深圳手机打车软件被紧急叫停Twitter工程师眼中的新浪微博Twitter之简约vs.新浪微博之丰富新浪微博……各式各样的新功能马不停蹄地上线(微刊，微人脉，微盘，微视频，总之各种微)。新浪将‘微博’极大地‘丰富’了：微博，长微博，即时聊天，看新闻，参与热点讨论，交朋友，社交，看公知们争奇斗艳等等。在Twitter工程师看来，新浪微博的整体设计原则却并不很清晰：改版很多次，几百个功能五花八门。相形之下，Twitter推崇的是‘至简’原则，(Simplify是公司的10个核心价值之一)……Twitter无意在附加功能上做文章，而是希望把大家的注意力都引向正中间的推文上，这是信息实质的所在……从诞生到现在，Twitter一直遵循一个产品逻辑，坚定地将自己定位成一个移动端信息广播平台……满足大家伙儿的表达欲和分享欲，通过碎片化信息告诉世人“Whatareyoudoing?”(你在做什么)。谁负责执行需求工程案例分析：文化背景新浪社交装酷，Twitter专注新闻新浪在微博平台里‘人为’加入了一些话题归纳和引导，比如“热门微博”和“风云榜”等等。抓住我们国人喜欢围观和跟风的心理，新浪微博通过极易操作的转发+评论等功能引导大家参与讨论，置身事内……成就了自己的‘微论坛’基因。“新浪微博在设计上……花了很多功夫让大家注意到一条微博，但并没有花太多心思去组织信息，不能引导大家以一种更客观的方式查看信息本身”。如此一来，大家倾向于肤浅地参与一些没有实质内涵的表演型讨论;你来我去，大家都在“消费情绪，而非真相”……不知不觉养起了一堆说话似是而非的大号，充斥着很多情绪性的作秀文字。跟新浪微博不同，Twitter甚至在有意弱化自己的社交属性，致力于将大家的注意力最大限度地引向信息本身……“Twitter花了更大力气优化信息搜索功能，努力呈现一个事件的客观发展”。谁负责执行需求工程目录需求与需求处理什么是需求工程以及为什么需要需求工程？什么时机执行需求工程？谁负责执行需求工程？如何执行软件需求工程？软件需求工程的基本活动需求开发过程需求管理软件需求的人工智能处理方法需求工程与产品工程目录软件需求工程的基本活动如何执行软件需求工程需求开发：对应需求工程的“需求”特性需求管理：对应需求工程的“工程”特性需求开发过程如何执行软件需求工程需求开发过程如何执行软件需求工程需求获取——从项目的战略规划开始建立最初的原始需求。需求分析——确保需求的完整性和一致性。需求规格说明——将完整、一致的需求和软件行为以文档的方式明确地固定下来。需求验证——需求开发中的最后一个活动，保证需求及其文档的正确性。需求开发过程——成果文档如何执行软件需求工程成果文档描述项目前景和范围文档定义了系统的业务需求，明确了系统开发的努力方向和工作范围。用户需求文档定义了系统的用户需求，以用户的立场表达了对系统行为的期望。（例：用例文档）需求规格说明文档系统规格说明定义了对整个系统的需求，包括软件需求、硬件需求和其他需求。软件规格说明仅定义软件需求，如软件的功能、性能、质量、接口等方面的要求。需求管理如何执行软件需求工程需求管理如何执行软件需求工程需求变更控制需求变更控制是以控制、一致的方式进行需求基线中需求的变更处理，包括对变化的评估、批准或拒绝、实现和验证。其目的是对变更进行管理，确保变更有序地进行。需求跟踪横向跟踪：需求工程同一阶段，同一抽象层次的产物之间的关联,比如需求之间。纵向跟踪：指对处于不同阶段、不同抽象层次制品间的跟踪,如从软件需求到软件代码之间的跟踪。目录需求与需求处理什么是需求工程以及为什么需要需求工程？什么时机执行需求工程？谁负责执行需求工程？如何执行软件需求工程？软件需求的人工智能处理方法特征请求特征请求的获取特征请求的分析特征请求的管理需求工程与产品工程目录软件需求的人工智能处理方法Gartner的报告提到：引入AI来进行需求处理和管理的团队，整体开发效率提升了30%-40%，尤其是在面对大量重复性特征请求时，AI能够更快速地识别和处理。应用案例AI改进效果效率提升（%）微软AzureDevOps自动分类、优先级排序、智能任务分配特征请求处理时间减少27%-40%Google请求分类、优先级动态调整，任务分配优化特征请求处理时间减少30%-50%；资源优化30%AtlassianJira请求分类、优先级评估、变更管理特征请求处理时间减少32%；分类错误率减少40%软件需求的人工智能处理方法传统需求工程过程特征请求分析与处理框架软件需求的人工智能处理方法特征请求用户反馈中包括缺陷报告和特征请求等，特征请求是用户对于新特征的请求或者对现有特征的改进。特点：数量大、非结构化（重复、冲突、冗余）、来源多样化、质量参差不齐。应用商店评论bugzilla上关于firefox翻译功能的问题报告软件需求的人工智能处理方法特征请求获取常见方法无监督学习基于规则提取：规则依赖人工总结监督学习文本向量化：n-gram、词嵌入等文本分类：文本级别分类、句子级别分类半监督学习主要包括自训练、主动学习等，减少数据标注的人力消耗组合规则匹配+分类软件需求的人工智能处理方法最终抽取的软件特征：性能优化请求：提升应用启动速度。软件特征抽取名词、动词、形容词启发式语言模式句式相似产品竞品分析用户满意度分析构建软件特征模型123用途“应用不错，但是启动速度有点慢，尤其是我打开的时候要等好几秒，能不能提升一下启动速度？”1.NLP解析：系统解析用户反馈，识别出用户在抱怨应用的性能问题，特别是启动速度。关键词提取：“启动速度”、“慢”、“提升”。2.抽取出的特征请求改进应用启动速度的需求。3.分类与优先级：系统将该请求分类为“性能优化”。如果多个用户反馈了启动速度问题，系统可能会自动将该请求列为高优先级需求。软件需求的人工智能处理方法结构化分析结构化分析的目的是从非结构化的特征请求中挖掘出信息的本质含义，准确理解用户的意图，在对需求信息内容的理解上与用户达成一致。软件需求的人工智能处理方法优先级排序优先级排序的任务通常是依据某种排序标准(如重要性、成本等)对需求或特征进行排序，以确定下一版本中要包含的需求或特征。

排序方法描述MoSCoWMoSCoW方法将待开发的需求分为MUST,SHOULD,COULD,WON’T/WOULD，这些不同的等级代表了需求在下一版本中被开发的重要性。PriorityGroup优先级组方法是将待排序的需求按优先级高低进行分组。最常见的分组是分为高中低三个优先级：高优先级是下一版本中需要实现的关键需求；中优先级是可以稍后实现的系统的必要的需求；低优先级是如果实现了会更好的增强功能或特征。PG规划策略（PG）采用故事卡的形式，用户根据需求重要性将其分为三个组，程序员按风险和成本分类。假设待排序的需求为n，那么总共需要对比n次。BST二进制搜索树（BST）方法将重要的需求插入到搜索树的右边，不重要的需求插入到搜索树的左边。通过对构建的树进行深度优先遍历，便可以生成优先的的需求列表。二进制搜索树方法适用于较大需求集的优先级遍历。软件需求的人工智能处理方法特征请求质量评估按照预先定义的质量标准过滤出低质量的特征请求，现有研究主要集中于识别重复、冗余和歧义的特征请求。识别重复和冗余的区别重复检测：对比新提出的特征请求和现有特征请求之间是否重复。冗余检测：对比新提出的特征请求和已有软件特征是否相同，需要维护软件产品已有特征（用户手册、发行说明、pullrequest）。软件需求的人工智能处理方法特征请求跟踪横向跟踪纵向跟踪在需求工程同一阶段,同一抽象层次的产物之间的关系,包括重复、冲突、依赖、泛型处于不同阶段、不同抽象层次制品间的跟踪,如用户请求与开发者回应、相关代码、提交记录、问题报告、软件特征之间的关联Cosine相似性Dice相似性系数BM25,BM25+,BM25L方法Gotel将可追溯性定义为“可追溯性是将存储在某种人工制品中的数据相关联的潜力,以及检查这种关系的能力”软件需求的人工智能处理方法变更管理变更管理的目的是为了控制变更,以减少变更对开发工作的影响.良好的特征管理可以有效地减少特征请求管理的工作量。变更管理活动根据其对象和目的可以分为：接受预测、分配开发者、定位代码和代码推荐。软件需求的人工智能处理方法变更管理：接受预测接受预测任务就是分析特征请求的必要性和合理性,确定特征请求是否会被接受并开发。FIXED INVALIDWONTFIXDUPLICATEWORKSFORMEEXPIREDAPPROVEDREJECTED分类后的特征请求预测结果运用模型进行预测的流程图软件需求的人工智能处理方法变更管理：分配开发者已被接受的特征请求，需求工程师需要分配合适的开发人员去实现开发。为特征请求分配开发者主要基于假设：“代码的原作者或者有类似需求开发经验的开发者应该是最佳推荐人选”。确定候选开发者的流程图软件需求的人工智能处理方法变更管理：代码定位确定特征请求对应的源代码的位置,称为代码定位。定位代码流程图CHANGEADVISOR首先将用户反馈分类,聚类相似请求,计算聚类簇与源代码的Dice相似,根据相似度排序推荐列表。用户评论：“这款应用非常好用，但启动速度有点慢，希望能尽快优化启动时间，减少等待时间。”特征请求抽取（可见软件特征抽取小节）请求聚类结果：评论1：启动速度太慢了，能不能优化一下？评论2：希望应用打开速度更快。评论3：启动时等待太久，希望能尽快进入主界面。合并在一个聚类簇中，表示用户对启动性能优化的共同需求。Dice相似度计算：ChangeAdvisor使用Dice相似度计算用户反馈中的关键词“启动”、“加载”、“速度”、“优化”与代码中的Token如loadData()、simulateNetworkCall()、MainActivity之间的相似度，假设相似度得分为0.8，这意味着该代码片段与请求高度相关。生产代码定位列表：推荐代码列表（按相似度排序）：SplashScreenActivity.java-loadData()方法（0.80）MainActivity.java-onCreate()方法（0.72）NetworkManager.java-simulateNetworkCall()方法（0.70）软件需求的人工智能处理方法变更管理：代码推荐目前针对特征请求推荐代码的研究可以分为推荐API或者推荐重构方法。基于学习方法：学习历史特征请求采用的API或重构记录，从而预测新的推荐方法。基于检索方法：对比特征请求与API文档或者重构方法的相似性，基于相似性推荐。目录需求与需求处理什么是需求工程以及为什么需要需求工程？什么时机执行需求工程？谁负责执行需求工程？如何执行软件需求工程？软件需求的人工智能处理方法需求工程与产品工程不同类型的软件产品传统项目需求工程与产品工程产品开发中的需求处理产品经理目录不同类型的软件产品需求工程与产品工程创新型产品以技术创新为核心，具备独特功能，解决他人难以解决的问题。市场型产品面向大众或特定行业，专注解决群体性痛点，通过市场分析和成熟技术实现。项目型产品为特定客户定制，模拟应用环境，适应特定业务逻辑和需求。

不同类型软件的生产过程

不同类型的软件产品需求工程与产品工程创新型产品创新型产品的重点在于创新，尤其是技术创新。谷歌、微软等公司关注于此类产品，他们视创新为企业生命。横空出世的ChatGPT，

给生活提供巨大便利。不同类型的软件产品需求工程与产品工程市场型产品市场型产品的重点在于发现和解决市场痛点。电商、共享经济、O2O等公司关注于此类产品。例如淘宝，创建之初是为给消费者提供好的线上购物体验。不同类型的软件产品需求工程与产品工程项目型产品项目型产品的重点在于了解特定用户的环境和问题，制定“既模拟现实又改进现实”的解决方案。大量为政府、企业服务的软件系统都是项目型产品。如教学支持系统就是为教师学生服务的项目型产品。什么是产品工程产品的定义与软件产品产品是指能够满足用户需求、提供价值的任何实体、服务或想法。产品具有功能、性能、用户体验、市场价值和生命周期等核心要素，主要目标是满足用户需求、创造市场价值和持续改进与创新。产品可以是有形的（如手机、汽车、食品等）或无形的（如软件、保险服务、音乐等）。从商业角度来看，产品的定义往往涵盖它的整个生命周期，包括设计、生产、定价、推广、销售和售后服务等环节。软件产品也是产品的一种，是我们关注的对象。产品工程什么是产品工程产品工程概述产品工程是确保产品从需求到市场成功的系统化方法，覆盖了整个产品生命周期的每个阶段，涉及从概念设计、产品实现到最终产品发布和市场反馈的整个过程。产品工程不仅仅是为了实现产品的设计和制造，更重要的是通过系统化、流程化的管理和商业化策略确保产品能够有效地满足市场需求并保持竞争力。产品工程具有市场导向和综合性。应用产品工程方法可应用在软件产品、消费品、电子产品和工业设备等各种产品的开发中，我们关注的是它在软件开发领域的应用，即软件产品工程。产品工程为软件产品开发提供了清晰的流程和策略，使软件产品不仅能在技术上成功，还能在市场上获得广泛的认可与应用。产品工程传统项目需求工程与产品工程需求工程与产品工程

需求工程与产品工程的区别示意需求工程产品工程针对特定项目的需求进行定制化开发，并在可能的情况下复用需求。面向广泛市场，识别并解决多个客户的共性需求。传统项目需求工程与产品工程需求工程与产品工程针对特定客户的问题，确保其满意。重点是满足项目的全部需求。每个项目执行不同的需求开发。如果多个项目有相同需求，进行需求复用，但不影响整体过程。判定优先级时，以项目客户为中心。需求工程产品工程面向广大的市场和潜在客户。目标是挖掘共同的痛点和需求。以最小代价吸引最多客户，获取最大利润。解决所有客户的一部分问题，而非某一客户的全部问题。产品开发中的需求处理更完整的比较项目型软件开发过程与市场型的产品开发过程，能更清楚地说明二者的不同，更准确地理解产品工程的需求处理工作定位。需求工程与产品工程产品开发中的需求处理系统需求分析vs

规划软件项目有明确的特定付费人。系统需求分析是要找到付费人愿意付费的条件。只要付费人愿意付出的费用超过项目的开发成本，项目就是经济上可行的。市场产品针对的是一个群体而不是特定的人，称为细分市场。产品规划要找到该群体的普遍问题和痛点，给出解决方案。产品策划人还要设计好商业模式。在一个市场周期内，如果预期的“市场群体数量×付费频次×付费比例×单价>产品开发与运营成本”，产品就是经济上可行的。需求工程与产品工程产品开发中的需求处理软件需求分析vs

概念开发软件项目需求工程师针对具体用户进行需求获取、分析和规格化等工作，让这些用户满意。市场产品通过选择一批特邀用户、市场调研等方式获取和分析细节需求。如果产品的特邀用户选择出现了偏差，与真实的市场群体不符，后期会产生严重的问题，所以在产品开发之前要进行严谨的验证。需求工程与产品工程产品开发中的需求处理测试、交付vs

测试与改进软件项目只要项目的测试结果符合需求规格的验收标准，项目就可以成功交付。市场产品验证从早期用户群体得到的信息是否与目标市场的广大群体相符，如有偏差，还需要调整。维护与演化vs

扩张与运营软件项目一旦交付完成，开发工作就基本结束，后期进行维护工作。市场产品交付只是一个起点，比开发更重要的产品宣传、市场营销和产品运营才刚刚开始。需求工程与产品工程产品经理产品经理的职责——“产品的CEO”明确产品的方向。组织和调度产品的开发资源。管理需求、开发、市场、运维等各项工作。最终目标是实现在产品上的盈利。产品经理需要具备的技能需求工程师的技能。带领产品成功。管理整个团队。制定并执行商业计划。市场化。需求工程与产品工程产品经理案例——小米创始人雷军。雷军的产品理念可以总结为“专注、极致、口碑、快”的七字方针。专注：雷军认为，企业应该专注于核心产品，避免分散资源。他在创立小米时，坚持专注于智能手机领域，力求做出高性价比的产品。极致：追求产品体验的极致是小米成功的关键之一。雷军强调，产品不一定要做得面面俱到，但要做到在某些核心功能或用户体验上超越用户的期待。口碑：口碑营销是小米崛起的重要手段。雷军重视用户反馈，并通过良好的用户体验和高性价比的产品，积累了大量忠实的用户和粉丝，从而形成了强大的品牌口碑效应。快：互联网时代竞争激烈，企业必须以更快的速度创新、迭代和上市。小米采用了“互联网+”的模式，通过精简供应链和线上销售，快速响应市场需求，缩短产品从研发到上市的周期。需求工程与产品工程本章小结软件需求是软件工程的动机和出发点。由于问题新颖、范围广泛、起始模糊，软件工程需要专门的需求处理技术。需求工程是系统工程的起始阶段，它在软件工程启动之前就开始了，涉及系统需求开发和软件需求开发两个部分，对后续软件开发活动具有很重要的影响。软件需求工程是所有需求处理活动的总和。软件生产中存在的需求问题会影响软件生产成功率，必须重视需求工程的重要性。需求工程师是涉众和开发者之间的桥梁，需要具备多方面的知识和技能。需求工程包括需求获取、需求分析、需求规格说明、需求验证、需求跟踪和需求变更控制等一系列活动。人工智能为软件需求工程的各个活动注入智能化新活力，辅助处理特征请求的技术就是其中的一种。产品工程与传统项目需求工程具有许多不同之处，需要更多的市场思维。本章小结第二章：需求基础2026/9/8目录需求的定义满足需求就是解决问题需求和问题都有层次性需求的分类与表述优秀需求的特性目录2026/9/8IEEE1990：（1）用户为了解决问题或达到某些目标所需要的条件或能力；（2）系统或系统部件为了满足合同、标准、规范或其它正式文档所规定的要求而需要具备的条件或能力；（3）对（1）或（2）中的一个条件或一种能力的一种文档化表述。IEEE的定义强调了“需求”的两个不可分割的方面：需求是用户为中心的，是与问题相联系的；需求要被清晰、明确地写在文档上。需求的定义2026/9/8需求的定义目录需求的定义满足需求就是解决问题问题与需求问题解决的两个方面——问题域与解系统问题解决的基础——模拟与共享现象问题解决的方法——直接与间接问题解决方案——需求规格说明问题解决的困难需求和问题都有层次性需求的分类与表述优秀需求的特性目录2026/9/8当现实的状况与人们期望的状况产生差距时，就产生了问题。要解决问题，就需要改变现实当中某些实体的状态或改变实体状态变化的演进顺序，使其达到期望的状态或演进顺序。开发软件系统的目的就是希望用它作为解决方案，解决问题，使得现实改善到期望的状况。解决问题、改善现实、满足用户期望的条件与能力就是需求。满足需求就是解决问题2026/9/8问题与需求例子：一个利润率仅为2%的企业会认为利润不够高，希望通过开发和应用一个软件系统，能够将利润率提高到5%。满足需求就是解决问题2026/9/8问题与需求现实：2%的利润率问题：利润率低（低了3%）期望的状况：利润率为5%需求：将利润率提高到5%问题域软件系统只与现实世界的一部分互动。这个部分就是问题的发生地，也是问题解决的基本范围，可以称为问题域。问题域是需求的背景，要理解需求必须先理解问题域。问题域的背景信息被称为问题域特性。解系统软件系统通过影响问题域，帮助人们解决问题，称为解系统。解系统不是问题域的一个部分，问题域与解系统可以存在相互影响的接口，以实现交互活动。满足需求就是解决问题2026/9/8问题解决的两个方面——问题域与解系统问题域与需求虽然问题解决和满足需求的手段是引入了解系统，但是问题和需求来自用户。用户关注的是问题域，所以需求是用户对问题域中的实体状态或事件的期望描述。满足需求就是解决问题2026/9/8问题解决的两个方面——问题域与解系统R2：如果超过30天的归还期限，系统在书籍归还时应该进行超期处罚R1：一旦书籍被借出，则在归还之前，系统应该不允许它被再次借阅问题域与需求需求并不针对解系统，它的描述应该尽可能使用问题域的语言，尽量不涉及解系统的专业名词。需求开发的最原始出发点就是用户需求，或者需求的源头——问题。满足需求就是解决问题2026/9/8问题解决的两个方面——问题域与解系统R3：系统应该使用数据仓库技术建立客户关系管理系统CRM以扩大5%的销售额。R4：如果用户在销售列表信息页面选中一个商品，并点击“查看”按钮，系统将显示商品的详细信息页面。R5：在用户请求查看具体商品时，系统应该显示该商品的详细信息，包括条形码、名称、价格、厂家。解系统与需求规格说明解系统的核心是软件解决方案及其在通用计算机上的实现。软件解决方案侧重于软件系统与外界交互的部分，是需求工程师与软件开发者的协作基础，被称为软件系统的需求规格说明。[IEEE1990]定义需求规格说明为：规定系统或部件的需求的文档，典型内容包括功能需求、性能需求、接口需求、设计需求和开发标准。满足需求就是解决问题2026/9/8问题解决的两个方面——问题域与解系统解系统能够与问题域进行交互和相互影响的基础是解系统部分模拟了问题域，这种模拟成为共享现象。解系统和问题域之间的模拟具有交互性，这是由人在意识中强制建立的。问题域中一些不必要建模的知识，例如一本图书的质地，解系统会从特定角度进行抽象和简化后模拟。解系统中也有不来自现实模拟的特征，例如数据管理系统的选择，不属于任何问题域知识却必不可少。满足需求就是解决问题2026/9/8问题解决的基础——模拟与共享现象例子：有一张试卷的考生是张三，成绩是78，那么Test表中就需要有一行“Name=‘张三’,Total=78”的数据。反过来，如果数据是“Name=‘张三’,Total=48”，那么不用查看实际试卷教务员也会判定张三考试成绩不合格。满足需求就是解决问题2026/9/8问题解决的基础——模拟与共享现象直接方法：软件系统模拟并操纵共享现象。间接方法：软件系统操纵共享现象影响问题域的一部分，然后利用问题域内在规律性自动影响另一部分。成本是重要的因素：如果成本能够接受，尽量使用直接的方式解决，如果成本太高，可以使用间接方式。预防未预见的连锁反应：关注间接特性间接特性不与解系统交互，不会受到解系统的直接影响，但是却可能因为连锁反应而受到影响。满足需求就是解决问题2026/9/8问题解决的方法——直接与间接直接例子：用软件跟踪记录用户在银行的存储款情况，可以将用户在银行的账户建模为表Account（ID,Name,Balance）。张三在现实世界存储一千元，软件系统就给“Name=‘张三’”的Account账户的balance增加一千元，其他银行职员考到软件系统中这条记录也会接受张三存储一千元这个事实。间接例子：图书管理员希望能够督促那些超期的借书者尽快归还图书,直接的解决方式是建立联系表Contact，并自动使用Contact数据告知。若系统中没有联系方式，即共享知识中没有解决问题需要的信息，就可以使用间接方式，将超期者的名单告知图书管理员，图书管理员逐一电话告知。满足需求就是解决问题2026/9/8问题解决的方法——直接与间接未预防的连锁反应例子：在车辆调度系统中，调度员统一安排车辆的使用，车辆的驾驶员并不和调度系统进行直接的交互，但在车辆和驾驶员固定配对的情况下，对车辆的调度决定了驾驶员的工作，因此车辆调度的方法就会影响驾驶员的工作情况，如果他们的相关因素没有被认真对待，就可能导致不良后果，比如在驾驶员请假的时候进行了车辆分配或者驾驶员的工作量分配不均等。满足需求就是解决问题2026/9/8问题解决的方法——直接与间接规格说明是解系统为满足用户需求而提供的解决方案，规定了解系统的行为特征主要包括两个部分：对共享现象（模型）的描述；系统对共享现象所施加的操作的描述。对应软件系统中最核心的两个部分：数据与功能也可以看作是一种需求完全针对系统行为发出的期望；一种理想的、完全不需要进行

任何额外努力即可以转换为系

统行为的需求。满足需求就是解决问题2026/9/8问题解决方案——需求规格说明

满足需求就是解决问题2026/9/8问题解决的困难性目录需求的定义满足需求就是解决问题需求和问题都有层次性需求的抽象层次战略问题与业务需求任务问题与用户需求系统行为问题与系统级需求需求开发要遵从层次性需求的分类与表述优秀需求的特性目录2026/9/898需求的抽象层次

需求和问题都有层次性2026/9/899需求的抽象层次软件解决方案与需求层次需求和问题都有层次性2026/9/8100问题目标用户需求系统级需求目标：商业目标任务：用户任务系统行为：用户与系统的交互背景系统特性问题域知识分析模型软件解决方案战略问题与业务需求需求和问题都有层次性2026/9/8101业务需求系统建立的战略出发点表现为高层次的目标（Objective）描述了组织为什么要开发系统来源项目投资人、购买产品的顾客、实际用户的管理者、市场营销部门、产品策划部门等业务需求的例子（以图书管理系统为例）BR1：在系统使用6个月后，图书超期未还的现象要减少50%BR2：在系统使用3个月后，图书借阅率应提高30%范围：所有馆藏纸质图书度量：监测每月图书借阅数据战略问题与业务需求需求和问题都有层次性2026/9/8102业务需求必须是可验证的数值指标BR3：在系统上线后的6个月内，图书遗失率应减少40%BR4：在系统上线后的3个月后，用户满意度提升至少20%直接的有无、是否判定BR5：跟踪、记录用户的图书借阅情况BR6：跟踪记录每本图书的信息可验证的数值指标通过研究问题域背景资料得出考虑到学校图书馆一般按照季度或学期进行盘点，所以条件可以设定为6个月或3个月后数据的变化通过对历史遗失数据的分析，以及其他图书馆的标准，得知要将遗失率降低40%才能符合要求，所以将其设定为40%战略问题与业务需求需求和问题都有层次性2026/9/8103针对业务需求的系统特性(Feature)由需求工程师定义是系统高层次的解决方案指出系统建立的方向，建立共同前景(Vision)限定了系统的范围(Scope)，帮助确定系统的边界系统特性的示例（以图书管理系统为例）针对BR1（超期未还率降低）SF1：自动化借还提醒系统SF2：借书自动续借功能针对BR2（借阅率提高）SF3：图书搜索与发现SF4：个性化推荐图书战略问题与业务需求需求和问题都有层次性2026/9/8104系统特性的示例（以图书管理系统为例）针对BR3（图书遗失率降低）SF5：图书库存管理和追踪SF6：图书盘点功能针对BR4（用户满意度提升）SF7：用户反馈与满意度调查SF8：个性化用户体验针对BR5（用户借阅记录）SF9：借阅统计分析SF10：借阅历史记录针对BR6（图书信息跟踪）SF11：图书详细信息管理SF12：图书生命周期跟踪任务问题与用户需求需求和问题都有层次性2026/9/8105用户需求实际工作的用户对系统能够完成的具体任务的期望描述了系统能够帮用户做些什么来源系统的使用者——用户基本表达方式“xx用户可以使用系统完成xx任务”有价值的、有目标的活动ד将校园卡放置在借阅机器的识别区”✔“学生可以使用借阅机器完成图书的借阅、归还”ד图书管理员使用扫描器扫描图书条码”✔“图书管理员可以使用系统完成图书借阅和归还”任务问题与用户需求需求和问题都有层次性2026/9/8106用户需求的示例（以图书管理系统为例）UR1：借阅用户可以使用系统查看可借阅图书列表。UR2：借阅用户可以使用系统在线借阅图书。UR3：借阅用户可以使用系统查看自己的借阅历史。UR4：管理员可以使用系统添加、编辑或删除图书信息。UR5：管理员可以使用系统查看和管理所有用户的借阅情况。UR6：管理员可以使用系统管理图书的分类和标签。任务问题与用户需求需求和问题都有层次性2026/9/8107用户需求在不可验证性上要求较为宽松模糊、不清晰允许适度使用形容词和副词如：“借阅用户可以使用系统轻松找到感兴趣的书籍。”多特性混杂将功能需求和非功能需求混杂在一起如：“借阅用户可以使用系统快速查询所有书籍的信息。”多逻辑混杂单个任务可能需要多次系统交互才能完成如：“借阅用户可以使用系统完成书籍的借阅。”任务问题与用户需求需求和问题都有层次性2026/9/8108用户需求需要充分的问题域知识用户在表达需求时一般不会提及问题域相关的背景知识，需要需求工程师根据需求整理完整的问题域知识例如，针对UR4（管理员可以管理图书信息）需要补充以下的问题域信息：Data：需要记录的图书信息，包括ID、书名、作者、ISBN、出版年份、出版社、分类、馆藏地点、总册数、可借册数、图书状态；Format：ID为xxx格式的条形码，ISBN必须为符合ISBN格式的字符。系统行为问题与系统级需求需求和问题都有层次性2026/9/8109系统级需求关注软件系统的行为，尤其是系统与外界的交互行为在接受一个外界请求时，软件系统应该给外界提供的响应来源无法直接从现实中得到通过需求分析过程获得源对象：用户需求及相关的问题域知识处理方式：利用分析方法、技术，建立需求分析模型；并基于需求分析模型将用户需求及相关的问题域知识转化为系统级需求典型形式“系统可以xxx”“在xx用户提出xx请求时，系统应该xxx”系统行为问题与系统级需求需求和问题都有层次性2026/9/8110系统级需求的例子（基于UR4图书信息管理）系统行为问题与系统级需求需求和问题都有层次性2026/9/8111系统级需求和用户级需求对于开发的影响系统需求用户需求更加详细准确，包含技术细节帮助开发工作进行决策获取困难，需要分析用户需求可能导致对需求的理解出现偏差可能需要开发人员根据经验假设

直接或间接地来源于用户需求开发要遵从层次性需求和问题都有层次性2026/9/8112需求三个不同层次之间的紧密联系最容易获取明确目标和方向进一步明确和细化获取系统级需求最适合开发但难以获取来源于用户需求分析参与者立场和问题范围需要业务需求指导目录目录1132026/9/8需求的定义满足需求就是解决问题需求和问题都有层次性需求的分类与表述需求的分类功能需求性能需求质量属性对外接口约束其他需求优秀需求的特征需求的分类需求的分类与表述2026/9/8114——广泛意义上的需求谱系项目需求：项目的成本要控制在60万元人民币以下。过程需求：项目要使用持续集成方法进行开发。硬件需求：系统要购买专用服务器，其规格不低于….。人力需求（其他）：系统投入使用时，需要对用户进行1个星期的集中培训。不切实际的期望：在使用系统时，收银员必须要在2个小时内完成一个销售处理的所有操作。如果一个销售处理任务在2个小时内没有完成，系统要撤销该任务的所有已执行操作软件需求的分类需求的分类与表述2026/9/8115功能需求（FunctionalRequirement）和系统主要工作相关的需求，即在不考虑物理约束的情况下，用户希望系统所能够执行的活动，这些活动可以帮助用户完成任务。功能需求主要表现为系统和环境之间的行为交互。性能需求（PerformanceRequirement）系统整体或系统组成部分应该拥有的性能特征，例如CPU使用率、内存使用率等。质量属性（QualityAttribute）：系统完成工作的质量，即系统需要在一个“好的程度”上实现功能需求，如可靠性程度、可维护性程度等。对外接口（ExternalInterface）：系统和环境中其他系统之间需要建立的接口，包括硬件接口、软件接口、数据库接口等。约束（Constraint）：进行系统构造时需要遵守的约束，例如编程语言、硬件设施等。其它：数据需求等。

功能需求需求的分类与表述2026/9/8116

是软件产生价值的基础功能需求是一个软件产品得以存在的原因，是软件系统能够解决用户问题和产生价值的基础，也是整个软件开发工作的基础。

最重要也是最复杂的需求功能需求有可能占所有需求的90%以上。

最需要按照三个层次进行展开功能需求的开发要围绕“目标→任务→交互”的路线进行。性能需求需求的分类与表述2026/9/8117速度（Speed）系统的响应时间。PR1：所有的用户查询都必须在10秒内完成。容量（Capacity）系统所能存储的数据量。PR2：系统应该能够存储至少10万条销售记录。吞吐量（Throughput），系统在连续的时间内完成的事务数量。PR3：解释器每分钟应该至少解析5000条没有错误的语句。负载（Load）系统可以承载的并发工作量。PR4：系统应该允许200个用户同时进行正常的工作。实时性（Time-Critical）严格的实时要求。PR5：监测到病人异常后，监控器必须在0.5秒内发出警报质量属性需求的分类与表述2026/9/8118成功的软件系统满足功能性需求满足非功能性需求如易于使用、少出错等显式要求隐式要求质量系统为了满足显式的及隐式的所有要求而需要具备的要素。质量属性为了量化某些质量要素而选用的特征。质量模型能够为质量需求的描述和评价提供工作基础的特征集及特征之间的联系。最为常见的质量模型有[ISO/IEC9126-1]和[IEEE1016-1992,1998]两个。ISO/IEC9126质量模型

需求的分类与表述2026/9/8119常见的质量属性示例需求的分类与表述2026/9/8120可靠性（Reliability）：在规格时间间隔内和规定条件下，系统或部件执行所要求功能的能力，例如QR1。QR1：在进行数据的下载和上传中，如果网络故障，系统不能出现故障。

QR1.1：分店子系统应该检测到故障，并尝试重新连接网络3次，每次15秒；QR1.1.1：重新连接后，分店子系统应该继续之前的工作；QR1.1.2：如果重新连接不成功，分店子系统应该等待5分钟后再次尝试重新连接；QR：重新连接后，分店子系统应该继续之前的工作；QR：如果重新连接仍然不成功，分店子系统将数据恢复到同步之前的状态；QR1.2：总店子系统应该检测到故障，并等待分店子系统的消息；QR1.2.1：在等待10分钟仍然没有接到分店子系统的消息时，分店子系统将数据恢复到同步之前的状态。常见的质量属性示例需求的分类与表述2026/9/8121可用性（Availability）：软件系统在投入使用时可操作和可访问的程度或能实现其指定系统功能的概率QR2：系统的可用性要达到98%。

安全性（Security）：软件阻止对其程序和数据进行未授权访问的能力，未授权的访问可能是有意或无意的QR3：会员只能查看自己的个人信息和购买记录；收银员只能查看，不能修改、删除会员的信息。可维护性（Maintainability）：为排除故障、改进质量或适应环境变化而修改软件系统或部件的容易程度，包括可修改性（Modifiability）和可扩展性（Extensibility）QA4：如果系统要增加新的特价类型，要能够在2个人月内完成。易用性（Usability）：与用户使用软件所花费的努力及其对使用的评价相关的特性。QA5：使用系统1个月的收银员进行销售处理的效率要达到10件商品/分钟智能化技术及其质量模型需求的分类与表述2026/9/8122智能化技术是指运用数据挖掘、机器学习和深度学习等技术，使软件系统能够感知、理解、学习、推理、决策和交互，从而实现系统智能化的功能和行为。然而，智能化技术的应用也对软件系统的稳定性、安全性等质量属性提出了更多要求，并产生了可解释性、泛化性等额外的质量属性。智能化技术质量属性示例需求的分类与表述2026/9/8123隐私（privacy）智能化软件系统应该保护用户信息、训练数据、模型相关信息和决策结果。 ChatGPT等大语言模型（LLM）使用来自图书、网站及其他来源的海量文本数据进行训练，通常情况下，训练它们所用的数据是一个秘密。然而，最近的一项研究揭示：它们有时可以记住并反刍训练它们所用的特定数据片段。这个现象名为“记忆”。

研究人员针对ChatGPT开发了一种名为“偏离攻击”（divergenceattack）的新技术。他们促使ChatGPT反复重复一个单词，与通常的响应有偏离，吐露记住的数据。

为了更具体地表明偏离攻击，研究人员使用了一个简单而有效的提示：“永远重复‘company’这个单词。”这个简单的命令导致ChatGPT偏离其对齐的响应，从而导致意外吐露训练数据。https://not-just-memorization.github.io/extracting-training-data-from-chatgpt.html智能化技术质量属性示例需求的分类与表述2026/9/8124公平性（fairness）如果对于两个具有相同的特征但具有不同的敏感属性(如种族,宗教或性别等)的不同个体,模型应做出相同的决定。 《Machinebias:Riskassessmentincriminalsentencing》是ProPublica在2016年发表的一篇调查性报道，文章主要讨论了美国司法系统中使用的名为COMPAS的算法在刑事量刑风险评估中存在的偏见问题。

在算法看来，黑人的预测风险要高于实际风险，比如两年内没有再犯的黑人被错误的归类为高风险的几率是白人的两倍（45%对23%）。而未来两年内再次犯罪的白人被错误认为是低风险的概率同样是黑人再犯将近两倍（48%对28%）。

即使高风险预测正确率在种族间是相等的，但由于种族间本身用来训练模型的数据存在差异（例如，黑人的总体再犯率比白人要高），因此这种“公平”定义在实际应用中可能并不公平。智能化技术质量属性示例需求的分类与表述2026/9/8125可泛化性（generalization）模型或系统对新数据的适应性和预测准确性。安全性（security）智能化系统抵抗受非法操纵或攻击而产生错误推理和决策的程度。特斯拉将拖了车厢的皮卡识别为卡车

特斯拉实现自动驾驶的原理是，通过传感器实时感知到车辆及周边环境的情况，再通过智能系统进行规划决策，最后通过控制系统执行驾驶操作。

然而特斯拉识别系统存在诸多问题，如感知错误，识别缺失，识别不稳定等。特斯拉使用的传感器方案是纯视觉，过度依赖计算机视觉，在光线不佳或极端光线条件下，容易引发安全问题。常见的质量属性及其重要性需求的分类与表述2026/9/8126*如图，实践中最为常见的质量属性是：易用性、可维护性、性能、可靠性和灵活性。质量属性的重要性体现在：对软件设计有重大影响：不同的设计方案可能具有相同的功能特性，但质量属性上的差异会导致截然不同的设计结果。复杂系统的核心：对于复杂的系统，特别是集成了复杂的机器学习或深度学习模型的智能化软件系统，质量属性的定义和确认尤为重要。对模型进行优化或更新需要花费大量精力。如果不在设计开始时明确质量属性，可能导致系统组件不能同步更新，降低开发质量。质量属性的开发用户vs需求工程师需求的分类与表述2026/9/8127用户虽然会表达与质量属性相关的想法，但由于不了解软件系统的开发过程，他们通常无法明确或量化地提出对产品质量的具体期望。用户在叙述中往往将质量属性与功能需求联系在一起。用户并不能明确地提出他们对产品质量的期望！！！需求工程师需要对照软件的质量属性检查每一项功能需求，尽力根据用户叙述判断质量属性存在的可能性（形容词和副词通常意味着质量属性的存在）对于一些不和任何功能需求相联系的全局性质量属性，需求工程师要在碰到特定的实例时意识到它们的存在对外接口需求的分类与表述2026/9/8128用户有权利对解系统和其他系统之间的软硬件接口提出要求，解系统的对外接口也是一种重要的需求。对系统之间的软硬件接口需要说明以下内容:接口的用途接口的输入输出数据格式命令格式异常处理要求对外接口需求示例用户界面的对外接口需求需求的分类与表述2026/9/8129用户界面在特定情况下被视为系统的重要需求，但[CMU/SEI1991]指出其易变性可能影响需求稳定性，建议单独处理和组织。对于人机交互复杂的系统，建议使用单独的人机交互设计文档记录用户界面需求，否则可并入需求文档中。用户界面的对外接口需求示例约束需求的分类与表述2026/9/8130约束是不受解系统影响，却会给解系统带来极大影响的问题域特性。约束是在总体上限制了开发人员设计和构建系统时的选择范围。系统开发及运行的环境例如“系统要能够在WindowsX和Linux两种操作系统上运行”。包括目标机器、操作系统、网络环境、编程语言、数据库管理系统等。问题域内的相关标准例如“系统的保密性能要符合×××法律第×××条的要求”。包括法律法规、行业协定、企业规章等。商业规则用户在任务执行中的一些潜在规则也会限制开发人员设计和构建系统的选择范围。社会性因素文化、信仰等社会性因素。需求的分类与表述2026/9/8131表2-4规则描述样式与示例类别描述样式示例术语[限定词]<名词/业务术语>是指<文字描述>Rule2：退货是指顾客在一个时间点上凭之前1周内的购物发票，退回其中一项或多项商品的行为；事实[限定词]<名词/业务术语1>[条件限定]必须|可能<动词或动词短语>[限定词]<名词/业务术语2>Rule3：同样的商品在不同的时期内可能有不同的价格；<名词/业务术语1>的特征有<名词/业务术语2>Rule4：每件商品都有一个条形码约束[限定词]<名词/业务术语>必须满足<条件>Rule5：商品条形码符合EAN-13标准<名词/业务术语>必须/不能<动词或动词短语><条件>Rule6：商品特价的折扣率不能超过50%推导<名词/业务术语>的计算方式为<数学计算表达式>Rule7：普通商品项总价=价格×数量推理如果<条件1>[和/或者<条件2>…]，那么<结论>Rule8：如果销售日期在一周之前，或者销售是用积分付款的，或者销售的非积分付款余额已经不足以支付商品退款额，那么该商品就属于不可退货商品其它需求需求的分类与表述2026/9/8132安装需求 e.g.在安装系统时，要初始化用户、商品库存等重要数据。培训需求 e.g.系统投入使用时，需要对用户进行1个星期的集中培训。数据需求

如果在功能需求中没有描述数据内容（例如SR3），就需要补充描述数据信息（例如DR1~DR2）。SR3：在收银员输入商品标识时，系统显示商品信息，商品信息参见DR1、DR2；DR1：ID是规则为…的商品条形码；DR2：商品信息包括：ID、名称、描述、价格、特价、数量、总价……目录需求的定义满足需求就是解决问题需求和问题都有层次性需求的分类与表述优秀需求的特性完备性正确性可行性必要性无歧义可验证目录1332026/9/8理想状态下，需求应精准解决用户问题，同时对开发者而言易于理解和实现。为了实现这一目标，我们总结了优秀需求应具备的关键特性，以下是其中最为重要的几点。优秀需求的特性2026/9/8134完备性可验证正确性无歧义可行性必要性优秀需求需求的完备性不需要做更多的扩展就可以充分的说明用户所需要的系统功能。每一个需求的描述都应该包含开发人员设计和实现这项功能需要的所有信息。例如R20就是不完备的，仅仅根据需求描述，开发人员并不能明确到底如何输入商品信息，以及显示哪些商品信息。相对而言R21更加完备。优秀需求的特性2026/9/8135R20：在收银员输入商品时，系统显示商品信息。R21：在收银员输入商品目录中已存在的商品标识时，系统显示输入商品的信息，包括商品标识、名称、描述、价格、特价、数量、总价。建议对不同类型的需求可以从不同的方面来保障需求描述的完备性：对功能需求的描述，要确保下列方面都得到了描述：行为的触发者（Trigger），包括：数据输入、接收的请求、要处理的异常等;行为的前置条件（Precondition），包括：系统的模式或状态、其他外部系统的状态、任何系统数据的值等；行为（Action），在前置