非功能需求不同于功能需求。
听起来像是一句废话。
但是你能说出它们有哪些不同吗？如果不能，不妨看看下文。
1非功能需求是跨界需求
一个非功能需求往往与多个功能相关，它是跨界的。正是由于非功能需求所具有的这种横切特性使得它们在分析和实现上的难度都要远高于普通的功能需求。
2非功能需求更容易让用户不满
当软件交付给用户之后，相比某个功能暂时未能实现，某些非功能需求没有实现会更容易让用户不满。比如运行速度缓慢。没有满足用户对非功能需求的要求更容易导致项目推迟交付甚至被取消。
3非功能需求对软件架构影响更大
跨界的非功能需求实现起来非常复杂，所以它们通常也会对软件架构有更大的影响。比如，在架构设计时，就不能让一个一个高性能的需求（高运行或处理速率）横跨软件架构中的多个层。由于在软件开发的后期对软件架构修改会占用大量时间，影响项目交付，所以在项
目一开始就要做好非功能需求分析，判断对软件架构的影响程度。
4非功能需求之间存在相互排斥的可能性更大
非功能需求之间经常互相排斥。比如安全性需求和易用性需求；健壮性需求和性能需求等等。这就是GJB5000A需求开发过程域的专用实践“分析需求以达到平衡”应该解决的问题。
5非功能需求的描述更需要细节
相比功能需求，非功能需求更需要细节的描述。功能需求描述得不具体的时候，需求分析人员还是能够知道怎么去
实现它；而像“响应时间要尽量快”这样的性能需求描述，需求分析人员是无法判断出它对软件架构有什么影响的，也不知道实现之后的软件是不是满足了需求。
最后，其实本文想说的不是非功能需求和功能需求的区别，而是想让开发人员更加重视非功能需求的分析、设计和实现，能够在项目早期就考虑非功能需求对软件架构、项目进度、测试策略和项目成本的影响。
这正是：
需求重视非功能，因其影响超功能
架构进度和成本，用户不满它更重
1、VTS（vehicle technical
specification）：整车技术规范。包括整车技术要求、核心价值、使用标准的条件以及相应责任条款。
2、SSTS（sub system
technical
specification）：子系统技术规范。是规定子系统的一系列要求（特征、性能、设计）以及认证方法的工程文件。
2、CTS（component
technical specification）：零部件技术规范。关于零件性能、设计要求以及达到规范要求的认证方法的工程文件。
本文首先介绍整车开发阶段及电子电气开发流程，然后针对功能需求开发，提出如何从市场分析Voice of Customer(VOC)开始，逐步进行Vehicle
Technical Specification(VTS)，Subsystem Technical Specification(SSTS)以及Component
Technical Specification(CTS)开发，将市场语言转化成技术语言。
• 整车开发阶段
整车开发大致分成4个阶段，如图1所示：
1)
起始阶段：此阶段主要进行方案策划，考虑市场细分、产品定位、开发成本、生产成本等相关因素，并完成项目可行性分析之后，确定新车型的设计目标框架。
2)
概念阶段：此阶段会进行整车概念规划、初始设计需求、供应商供货能力、工厂产量分析、市场活动概念、售后概念、创新设计评估、整车性能评估等工作，设计能力较强的主机厂还会在此阶段引入虚拟车辆开发技术，进行前期建模仿真，辅助明确设计指标。
3)
开发阶段：前一个阶段中，主要制定技术指标。本阶段进行工程设计，完成部件设计、整车集成、样车制造、测试验证、生产前准备等工作，以满足设计需求。
4)
量产/维护阶段：本阶段需要确认实际产品是否满足功能及物理开发需求、确认产量与质量达成目标，确认成本与利润满足经济目标。对于售出的车辆，执行维护与品质保证等活动。
• 电子电气开发流程
我们所熟悉的电子电气开发流程(V模型)，包含需求开发、设计与仿真、部件开发与验证、集成验证等阶段。V模型会在整车开发阶段的概念阶段后期开始进行，并且贯穿整个开发阶段至量产/维护阶段，如图1的**覆盖区域。
本文提出的VOC/VTS/SSTS/CTS的开发活动，主要位于电子电气开发流程中的需求开发阶段。除了功能需求之外，需求开发也需要考虑法律法规以及非功能性需求(non-function
requirements)，由于篇幅原因此部分本文不再描述。
• 阶段1
–from VOC to VTS
阶段1- from VOC to VTS主要是使用技术语言来描述市场期望的车辆性能或特性。
市场部门完成一系列的市场调查之后，发布VOC研究报告（例如市场客户结构、市场购买因素、尺寸定位分析、领导车型感知、产品属性重要性等。），工程团队依据VOC，制定出满足市场需要的VTS。VTS为最顶层的需求，主要描述车辆与使用者的交互关系以及性能目标。通常包含汽车空间配置、总成配置、性能要求、气体动力学、尺寸空间、底盘系统、汽车刚性、外界接口、车辆人机界面、空调系统、各种模式NVH、操控性、刹车系统、生命周期、耐久性、道路安全、车辆回收等方面。
性能目标设定除了参考既往经验、团队能力之外，目标客户期望以及未来趋势都是关键因素。因此，性能目标的设定必须基于深厚的设计经验并且进行有效的语言转化。此阶段通常需要大量对标工作以及主观判断来支持性能目标的制定。
我们可以通过市场输入、对标分析、生产组装分析、模拟分析、权衡分析等等方式来开发VTS。也可以引入质量管理工具Quality
Function Development (QFD)如图3，进行分析，得出基本车辆信息。
• 阶段2
- from VTS to SSTS
本阶段主要基于VTS来开发SSTS。前一阶段所产生的VTS，对于特定性能已经有了明确的指标。在本阶段使其设计需求更加具体。
SSTS达到承先启后的功能，满足上一层VTS需求，并建立下一层CTS需求。SSTS对复杂的功能进行有结构性的拆解与分析，并且定义多个部件的组合行为，以及各个子系统的交互信息及方式。
SSTS相较于VTS更加具体，描绘信号交互、功能逻辑、场景分析等等。而SSTS相较于CTS更加抽象，通常不涉及包装、实现方案、详细原理、环境测试等等内容。也因为抽象性，SSTS才具备通用性的特点。SSTS能够独立于实现方案，却又为实现方案约定一种设计框架，使供应商在这个框架之中，能够进行各种创新或者降低成本设计，但又不会偏离初始的设计需求。因此车厂在选择供应商方案时，能够基于SSTS，去挑选品质与成本最优的方案。
• 阶段3
- from SSTS to CTS
本阶段目的是将SSTS的功能点通过功能分配，将设计需求分配给不同的部件来实现。而一个功能点可能与多个部件相关。
CTS为部件技术规范，此规范详细描述供应商所提供的控制器设计原理，包含控制芯片要求、电气原理图、控制功能逻辑、交互信号、睡眠唤醒、电气特性、性能测试等方面。
SSTS主要以子系统为中心，由多个部件共同实现。而CTS主要以控制器为中心。CTS一般由供应商提供或确认，其内容必须满足各个SSTS中的需求内容。三者关系描述如下图4。
本文描述功能需求开发工作在整车开发过程中的所在环节，并且介绍VOC/VTS/SSTS/CTS的含义及相互关系。通过VTS定义整车的性能指标，由SSTS描述抽象的逻辑关系，由CTS说明实现方案。每个阶段转化都需要大量设计经验与工程技术人员的支持。希望通过本文让读者了解正向设计流程的面貌。除此之外，就开发方式而言，有两种方式，一种是Top-down(由上至下)，另一种Bottom-up(由下至上)。而要完成一个高度平台化、易于裁剪的电子电气架构设计，必须采用Top-Down的设计思想，这也是国内自主品牌车企不断努力的方向。
不要脱离实际环境有时，我们会因为读到一篇文章或一本书，或者看到一个感觉不完善的介绍而变得异常偏执。在每种情况下，人们只讨论一些技术、解决方案和选项的某些方面，而忽视了一个至关重要的问题：非功能性需求。诚然，功能性是非常重要的。毕竟，如果您不能展示您构建的系统实现了您想要的功能，那么谁会有兴趣呢？采取一种新颖、巧妙、更简单、更漂亮或更得体的方法来解决某种问题固然很好，但是如果您没有考虑非功能性需求，则您的解决方案可能无法取得实效。非功能性需求是这样一种需求，它不一定解决“我想要我的系统实现这种功能”，而是解决“如何使这个系统能在实际环境中运行”。对于这些实际环境，您很少听到人们提及的一些问题是：MILY: 宋体; mso-bidi-font-size: 100pt; mso-ascii-font-family: 'Times New Roman'; mso-hansi-font-family: 'Times New Roman'; mso-bidi-font-family: 'Times New Roman'; mso-font-kerning: 10pt; mso-ansi-language: EN-US; mso-fareast-language: ZH-CN; mso-bidi-language: AR-SA">◆对在线系统的请求过多：用户太多了，全都在一块了！◆部署应用程序的管理员负担过大：在实际环境中，管理员对每个应用程序都将部署多次，而在部署之后必须对每一个应用程序进行监视。◆管理员会犯错误：毕竟，我们大多数都是普通人！虽然无差错地执行100 次手动部署步骤在理论上是可能的，但是实际环境中没有出现过。◆会有恼人的脚本小子 (script kiddy) 和真正的破解高手攻击我们的系统：安全是多么重要啊！可靠性需要考虑的一些具体方面是：可用性如果用户不能够从他们可用的渠道（例如 Web）方便地访问您的产品，那么它的好处何在呢？这有时是作为功能性的一部分一起考虑（或者应该在理想的环境下）的，但是常常被忽视，以致于整个项目处于危险之中。这里需要考虑的一些问题是：◆您是否为用户带来不适当的负担（例如，需要特殊的浏览器版本）？◆系统是否根据模型-视图-控制器 (Model-View-Controller) 体系结构设计以使多用户界面成为可能？如果是这样，如何将它们绑定在一起？◆是否界面本来就有状态而功能无状态（反之亦然）？有效性如果没有有效地使用资源（例如处理器、内存和磁盘空间），功能性、可靠性和可用性再好的系统最后都会失败。我们经常发现将有效性划分成两个子范围是很有用的，这两个子范围都应该加以考虑：◆性能：这个系统的运行情况有多好？它只是平稳缓慢地运行吗？系统可以达到其响应时间目标吗？应用程序的设计是否符合性能要求？您利用缓存了吗？◆可伸缩性：如果系统在小范围内运行看起来相当快，那么当扩展至每秒、每分钟或者每小时几千或成千上万个活动的时候呢？它的设计是否达到吞吐量目标？可以复制系统来实现线性扩展吗？是否存在瓶颈（例如公共数据库）？可维护性这是一个极其重要的需求，因为如果开发人员、管理员和操作人员不能够解决如何管理应用程序的问题，则它在首次发布之前就会夭折。假设您是一位管理员，您承担了解决此问题的任务，那么您如何配置它？如何监视它？如果您一件事情需要执行很多次（例如，安装许多应用程序），那么会怎么做呢？您是否有一个可复制的部署流程呢？您是否可以使重复的任务自动化，使之在大范围内可行呢？可移植性虽然列在最后，但它并非最不重要。例如，如何采用标准来提供某种形式的平台中立性呢？是否计划将应用程序迁移到您的最新和最高版本的应用服务器上呢？如果不打算这样做，则当供应商撤消对该版本的支持时您要怎么做呢？如果您的项目基于开放源代码，则也有类似的问题。如果每当某人有个更好的捕鼠器 (mousetrap) 您就必须重写整个应用程序，则没有人会问津。在完美的世界中，我们希望每篇文章、论文、红皮书、幻灯片和系统设计都率先解决这些重要问题。它们非常重要。差不多始终都要进行一些折衷，它们应该显式进行以便确定特定的设计是否符合您的需要。如果您阅读的文章没有解决这些问题，将这作为我们的警告——一些重要的东西往往会被忽视。如果您是一位作者，请考虑我们的恳求：不要忽视这些问题！
早期的时候，甲方处于自身对软件技术的了解和自身对系统未来维护的方便性考虑等，对系统有了诸如：开发平台、技术流派、关键实现等等方面的要求，这被称之为：“设计约束”。从甲乙双方合同的角度，设计约束也是一种需求------一种“非功能”性的需求。后来，软件的质量问题越来越突出，描述软件质量目标的要求也成为非功能性需求的一部分。于是，目前业界关于软件的非功能性需求，一般就包括：质量属性要求（质量目标）和约束性要求。关于软件的非功能性需求的开发，一致以来没有什么典型的方法论。我根据自己的一些实践经验，这里总结出来一个非功能性需求开发（获取和分析）的一般过程，一起探讨。 （一）先看一下如果获取和分析软件的质量属性要求（甲方未直接或明确提出来）。过程如下：（1）遍历每个软件质量属性，从宏观层面找出可能存在的质量要求。发现支持每个质量要求的依据。（2）分析质量属性的冲突。（3）确定质量属性的优先级。（4）选择排名靠前的几个作为关键质量属性。 案例： 一个大型自动化仓库管理控制系统，其用户有大型快寄公司如UPS、DHL、中国邮政，大型卖场如沃尔玛和制造公司如奔驰等。该系统需要进行仓储管理、货物调度等。另外，甲方要求系统将来可以更换硬件平台。 第一步：我们逐个分析是否存在哪个软件质量属性，并找出其存在的依据（（1）-（2）步骤一起执行）。 性能？ 非实时系统，但不能拥塞和长时间故障 ，否则影响运行吞吐量，影响企业的核心利润。所以，性能问题是该系统需要考虑的一个重要质量属性。 安全性？ 系统要确保设备操作安全，故障率低，不发生工人伤亡。确保系统指令不出错。 所以，安全性也是该系统需要考虑的一个重要质量属性。 持续可用性？ 以设备为生产线的企业，最大限度的利用设备是企业的基本运营原则，所以24小时X7天/周的持续可用性是必须的。 所以，持续可用性安全性也是该系统需要考虑的一个重要质量属性。 可互操作性？ 不存在与其他系统的数据交换和业务协作等互操作。 可靠性？ 没有象诸如电信计费那样的可靠性要求。
分析一下需求的具体内容：
·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。
·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。
·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。
·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。
·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。
在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。 优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系
客户的需求观
客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。
1、 分析人员要使用符合客户语言习惯的表达
需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。
2、分析人员要了解客户的业务及目标
只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。
3、 分析人员必须编写软件需求报告
分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。
4、 要求得到需求工作结果的解释说明
分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。
5、 开发人员要尊重客户的意见
如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。
6、 开发人员要对需求及产品实施提出建议和解决方案
通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。
7、 描述产品使用特性
客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。
8、 允许重用已有的软件组件
需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。
9、 要求对变更的代价提供真实可靠的评估
有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。
10、 获得满足客户功能和质量要求的系统
每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。
11、 给分析人员讲解您的业务
分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。
12、 抽出时间清楚地说明并完善需求
客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。
13、 准确而详细地说明需求
编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。
在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。
14、 及时作出决定
分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。
15、 尊重开发人员的需求可行性及成本评估
所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。
16、 划分需求的优先级
绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。 在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。
17、 评审需求文档和原型
客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。更好的办法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。
18、 需求变更要立即联系
不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。
19、 遵照开发小组处理需求变更的过程
为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。
20、 尊重开发人员采用的需求分析过程
软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。
“需求确认”意味着什么
在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”
这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”
同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”
这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。
对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。 需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。希望可以帮到你!
一、需求分析理论
软件需求涉及功能性问题非常广，我们用抽象化理论分析，可以划分各个功能域，用不同的数字代替，软件——S，功能域——A1、A2……An
S＝{A1、A2、……An}
但是功能域B又存在若干问题P1、P2……Pm组成，并且每个功能对应于子系统中的一个软构件，可以表示为-B＝{P1、P2、……Pm}
功能G有若干个行为F1、F2、……Fj，每个行为对应于软件构件中的实现方法
G＝{F1、F2……Fj}
一个软件包含了所有功能的集合，同时包含了实现所以功能的所有方法和算法描述。需求分析是依据用户动机，经过需求问题识别，进行分析、消除分驰和综合，编写用户故事，评审；形成用户需求与设计同步，设计满足用户需求目标。
需求开发方法贯穿这个产品生命周期，利用不同的开发方法论进行挖掘需求，帮助用户找到问题，梳理问题，判断产品实现功能的正确性、一致性和完整性，促使用户在软件设计启动之前进行周密的、全面的思考软件产品功能，用商业化行为解决需求与现实中存在的矛盾，解决用户需求与商业化产品功能融合，解决规范和个性化需求。
二、软件需求开发的目标
1、对实现的软件做一个全面的描述，帮助用户找到问题矛盾解决用户场景痛点，帮助用户在进行产品规划时做到周密，全面产品定位需求
2、了解和描述软件实现所需的全部信息，为产品设计、确认和验证提供一个基准
3、为软件产品管理人员进行软件产品成本评估和编辑软件开发计划书提供保障
需求开发-软件功能需求、软硬接口、非功能性需求、设计约束、反向需求、阅读支持信息。
软件需求分析尽量提供软件实现功能需求的全部信息，使软件设计人员和测试人员不在需要和需求方进行接触，保证需求分析的一致性和完整性。
三、软件功能需求
描述软件功能实现注意——
1、功能需求的完整性和一致性
2、功能描述的无异议和可追踪
3、功能描述清洗和功能可测试
四、软硬接口
1、人机接口
2、硬件接口
3、软件接口
4、通讯接口
五、非功能性需求
1、运行环境
2、时间需求
3、处理容限、精度、异常处理机制等
4、可靠性要求、可维护性、安全性
容量、性能、可修改性、可用性、安全性、易用性等。非功能性验收条件包括容量、性能、可修改性、可用性、安全性、易用性等。其中的关键点在于，当与某个具体用户故事或需求相关的验收测试成功后，就表明这个用户故事或需求已满足验收条件，可以认为它已完成并且是可正常工作的。
以上就是关于和功能性需求相比为什么更难确定哪些系统构件实现了非功能性需求全部的内容，包括:和功能性需求相比为什么更难确定哪些系统构件实现了非功能性需求、汽车开发中VTS/SSTS/CTS怎么理解、为什么非功能性需求很重要等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！
