基于MBSE的复杂装备系统设计：理论与实践 课件 5 工程化需求管理

总标题

——工程化需求管理本幻灯片中的图片为教学中多年的积累，无法逐一列出出处，在此统一鸣谢！本幻灯片仅应用于教学，无任何商业用途说明：1.1需求表达1.2需求追溯1.3需求变更第X章

工程化需求管理用户需求获取1.1需求表达需求获取是需求开发工作的第一个环节，也是连接需求规划和需求开发领域的中间环节。需求获取是一个理解并确定不同用户的需要和约束的工作活动。获取用户需求位于软件需求三层结构中的中间一层，具有承上启下的作用。需求获取是一个需要高度合作的活动，而不是简单对需求规划的照搬。作为一个需求分析人员，必须全面、细致地了解需求规划中的问题和目标、组织和对象、业务域、业务过程、业务活动、业务单证等内容，并不断思考系统应该提供什么样的功能来改进客户的工作。下面是需求获取的思路和过程：定义需求目标和范围；确定需求获取的方法和渠道；进行需求分析；确定需求优先级和约束条件；做好系统关联分析及描述；确认需求并制定使用用例；评审使用用例的描述；需求获取的方法1.1需求表达（1）面向目标的方法面向目标的方法强调将软件开发过程中的关注点从功能特性转移到业务目标，通过对系统所需实现的目标进行层次化描述，从而将需求文档结构化、分层、有序地表达出来，从而提高需求文档的可读性、完整性和一致性。面向目标的方法的核心思想是将需求从系统的功能特性中抽离出来，转而以用户的业务目标为中心进行描述。在这种方法中，需求被看作是系统实现的目标，这些目标具有层次结构，从高层次的目标开始描述，逐渐细化为底层实现的技术需求。（2）基于场景的方法基于场景的方法基于对应用环境的某一特定情境的描述来阐述用户的需求。这种方法通过场景的描述，可以让利益相关者之间更加清晰地理解系统的需求，从而便于利益相关者之间的交流和需求确认。此外，基于场景的方法还提供了一种将需求与实际相结合的机制，能够有效地帮助进行快速原型生成等活动。在实践中，可以通过场景描述的形式化，实现对用例的验证和快速原型生成等活动，提高系统开发的效率和质量。需求获取的方法1.1需求表达（3）质量功能展开质量功能展开（QFD）是一种结构化的方法，通过将客户的意见融入产品开发过程，使产品和服务的设计满足客户的要求。QFD是一种系统的、以团队为导向的产品开发方法，它利用矩阵将客户要求转化为产品规格。QFD是基于跨职能团队工作的原则，这意味着来自不同职能领域的代表，如市场、工程和制造，共同开发产品设计。这种跨职能的团队方法确保产品设计的所有方面都得到考虑，并确保最终产品满足客户的需求和期望，客户需求矩阵就是这种跨职能团队工作过程中的一个关键工具。规范化的需求条目1.1需求表达目的：作为项目的基础作为合同的基础精确描述要做什么可测试和可判定的需求有控制的配置基础明确区分需求和方案描述描述语言：自然语言自然语言是日常生活中使用的语言，它具有易于理解和编写的优点。但是自然语言存在语义的二义性和含糊性，容易导致需求理解的错误。因此，在使用自然语言描述需求时，需要进行详细的分析和澄清。形式化语言形式化语言是基于数学方法提出的一种抽象描述语言，它具有严格的语法和语义规则，可以排除自然语言的二义性和含糊性。但是形式化语言的使用需要具有一定的数学和逻辑知识，因此学习成本较高。结构化语言结构化语言的优点与自然语言较为接近，易于理解和阅读。由于其文法和词汇受到一定的限制，用它描述工程的需求规格说明可以为需求信息的一致性和完整性检验提供准则，从而部分地排除需求规格说明中存在的某些二义性，SysML语言就是一种典型的结构化语言。需求条目的结构标准1.1需求表达每个需求都要描述得清楚明了，这是开发工程项目的必要条件。需求文字描述应该结构清晰、易于理解。需求条目的描述模板1.1需求表达需求文档1.1需求表达在使用选定的方法对需求进行分析后，以可视化的形式持续记录需求是至关重要的。需求工程师需要对其进行建模和分析，细化为系统需求并建立能够满足系统需求的解决方案，从而形成需求文档。编制需求文档不仅可以帮助需求工作人员更好地理解问题域，使文档表达的知识更准确清晰，还能定义清晰、正确、规范的需求文档，为开发人员、项目管理人员和软件用户提供相对稳定的可阅读资料。需求文档模板1.1需求表达在需求文档的编写过程中，文档一般是分层的，对于多个层次采用节和小节来组织。适当的需求文档结构能够最小化需求的总量，理解大量信息，找出与具体问题有关的需求集合，发现遗漏和重复，消除需求之间的矛盾，管理迭代（如延迟提出的需求），拒绝差的需求，评估需求，以及在多个项目中重用需求。表格所示为符合IEEE830标准的需求文档的模板。需求追溯与可追溯性1.2需求追溯需求、项目计划和成果在项目开发过程中动态变化。变化来自工作进展、新的知识和关系、客户需求变更。需要进行控制和追溯需求，以识别其对项目和项目结果的影响。需求追溯还可以分为需求彼此之间的水平追溯和从需求到其他项目成果的垂直追溯。水平追溯可以回答一些关键问题，如单个需求如何联系、一个需求的变更如何影响其他需求等。在水平追溯中，需要建立一个模型来展示需求之间的相互依赖关系，以便在设计、开发和测试过程中更好地管理这些需求。垂直追溯是指从需求开始向下追踪到其他项目成果的过程，它涉及项目管理、变更管理和质量保证等方面。垂直追溯有助于评估项目进度、控制需求变更，并在项目审查时明确地了解项目的进展状况。需求追溯与可追溯性1.2需求追溯可追溯性正式表明两个或多个开发成果之间的关联程度。可追溯性允许在项目过程中，从客户的角度来衡量每个开发成果的功能和用途，如从已经测试并集成过的市场需求中可以衡量项目目前已创造的价值。保持条理清晰的可追溯性有助于进行影响、覆盖率和效益分析：影响分析展示了需求实施对整个方案及需求变更对已交付工作成果的影响，是功能导向变更管理的基础；覆盖率分析展示了已经完成并测试过的功能，并以此为基础推进项目进度；效益分析回答了为什么做出特定设计决策和系统需要哪些功能的问题，如果不能从功能或行为追溯到需求，就会产生特例或不必要的修饰，导致额外的成本或质量问题。可追溯性可以帮助控制开发过程中的所有关键步骤都实施了，可以追溯从需求到产品特性、现有系统的组件和开发过程中的工作成果。需求追溯矩阵1.2需求追溯需求追溯矩阵是一种表格，用于映射和追溯用户需求，通过测试用例来验证需求的完整性和正确性。需求追溯矩阵可以帮助确保100%的测试覆盖率，显示需求/文档不一致，显示整体缺陷/执行状态，重点放在业务需求上。除了单独维护一个excel表格，测试团队也可以选择测试管理工具来维护需求追溯矩阵。需求追溯矩阵的创建由需求开发人员、测试用例编写人员、设计人员等负责，而过程与产品质量保证（ProcessandProductQualityAssurance）负责检查是否建立了需求追溯矩阵及是否所有的需求都被覆盖了。在实践中，基本共识是纵向追溯是必需的，而横向追溯则不一定需要。可追溯性指标1.2需求追溯可追溯性向下通过需求层次推进有三个重要指标，分别是宽度、深度和成长度。宽度表示关系向下覆盖的层次程度如何；深度表示关系可以向下延伸到多少层；成长度表示关系通过层可以向下扩展多少。宽度：宽度与覆盖率有关，层指标也与覆盖率有关。在上一节已经提到过，覆盖率可以用来度量在单个层建立可追溯性的过程进展。宽度度量需求在多大程度上被相邻的上层或下层覆盖。宽度指标的目的是确保项目团队考虑到了所有的需求类型，并且没有遗漏任何一个重要的需求。深度：深度研究从给定层次开始，可追溯性向上或向下扩展的层次数，是一种全局指标。可以通过深度确定最下层需求的来源，如确定有多少组件需求实际上来自涉众需求、有多少组件需求来自设计。成长度：成长度更有意义，它反映了下层有多少需求与顶层的单个需求有关。可追溯性指标1.2需求追溯可追溯性的成长度有以下四种情况：在图（a）中，单个需求被下一层的单个需求满足。成长度因数为1。在图（b）中，单个需求被六个需求满足，成长度因数为6。这说明了两种需求之间存在以下可能：图（b）可能描述得很差，需要分解为多个需求。图（b）本质上比图（a）复杂，因此需要特别关注。变更图（b）产生的影响比变更图（a）大，因此需要特别关注。当然，一个层次上的明显不平衡可以通过下一层解决。这种情况可以通过图（c）和图（d）说明，其两层以下的成长度因数是相同的。这说明了两种需求之间存在以下可能：图（c）中的顶端需求层太高了。图（d）中的中间需求层太低了。可追溯性指标1.2需求追溯平衡：指标的一个思想是研究两个给定层次之间个体需求的成长度因数分布，检查这种分布外层四分之一中的个体需求。目标是标识具有异常高或低的成长度因数的需求，并进行特别关注。右图所示为一种典型的成长度分布情况，采用成长度速率和拥有该成长度速率的需求数表示。大多数需求都在2和6之间，少量需求只有1，或者大于6。正是这类成长度大于6的需求需要标识并特别关注。技术状态管理1.3需求变更技术状态（Configuration）是指在技术文件中规定的及在产品中达到的功能特性和物理特性。技术状态管理（ConfigurationManagement,CM）是指在产品生命周期内，为确立和维持产品的功能特性、物理特性与产品需求、技术状态文件规定保持一致的管理活动。管理活动主要包括技术状态管理策划与监督、技术状态标识、技术状态控制、技术状态记实、技术状态验证与审核，并应在产品的生命周期内开展技术状态管理，遵循需求牵引、要求明确、状态清楚、过程受控、分层管理、分类实施、记录完整、保持一致的原则。技术状态管理的目的是确保产品的技术状态清楚、一致。在产品生命周期过程中，技术状态管理主要发挥以下作用：支撑开展产品分解，确定管理重点，为建立技术文件体系、工作分解结构，以及资源配置奠定基础。确保实行技术要求的分解分配及文件化，为利益相关者提供完整准确的正式输入。建立技术状态基线，形成稳定、固化的技术状态，确保技术工作有序、质量可信。建立产品和文件标识，确保能清晰准确识别技术状态，避免出错。控制技术状态更改和偏离，确保产品质量与设计规定一致。全面提供技术状态信息，支撑各项技术工作和管理决策。基线1.3需求变更按技术状态的标识方式，技术状态基线可分为技术文件规定类型和实物技术状态类型。技术文件规定类型的技术状态基线，用于确定基线建立后的任意批次和数量的产品在实现时应满足的技术状态；实物技术状态类型的技术状态基线，用于确定特定产品实物的技术状态。技术文件规定类型的技术状态基线可按下列划分维度形成相应的类别：（1）按性质分：功能基线，用于确定产品级的设计与验证要求，关键作用是作为产品级的符合性验证依据。分配基线，用于确定产品级要求向子产品（技术状态项）的传递，关键作用是作为子产品级的符合性验证依据。产品基线，用于确定满足产品设计输入的全套设计结果，关键作用是作为产品级及其零部件的采购、制造和检验验收的依据，以及使用维修等的依据。其他基线，在功能基线、分配基线和产品基线的基础上衍生或抽取部分内容而形成，如需求基线。基线1.3需求变更按技术状态的标识方式，技术状态基线可分为技术文件规定类型和实物技术状态类型。技术文件规定类型的技术状态基线，用于确定基线建立后的任意批次和数量的产品在实现时应满足的技术状态；实物技术状态类型的技术状态基线，用于确定特定产品实物的技术状态。技术文件规定类型的技术状态基线可按下列划分维度形成相应的类别：（2）按适用范围分：型号主基线，以产品型号为对象，包括产品型号的功能基线、分配基线和产品基线。批次基线，以产品型号的研制生产批次为对象，如初样机研制批、正样机/试样机研制批订购生产批，可包括批次的功能基线、分配基线和产品基线。单件技术状态，以产品型号的单件或同一状态的小批量为对象，参考产品基线的内容范围而确立。单件技术状态通常强调产品组成，可采用产品明细表、产品结构视图进行表示。基线1.3需求变更基线建立的时机和标志：不同阶段各基线的标识符：技术状态更改控制1.3需求变更产品技术状态的更改、偏离和超差都应该进行控制，以保证最终实现规定的物理特性和功能特性。技术状态更改一般分为I类、II类和III类。其中，I类更改对功能基线和分配基线有影响，即对外部其他产品有直接影响的更改，如性能和功能、外形尺寸、接口特性等超出规定的限值或容差值；II类更改对功能基线和分配基线无影响，但对产品基线有影响，即对外部产品无直接影响但对本产品的质量有影响的更改；III类更改仅有文字性的修改，对产品实物质量无影响，如勘误译印、修正描图、统一标准方法等。需求变更1.3需求变更项目需求变更是不可避免的。根据需求工程的定义，需求文档应该经过验证。在验证后，如果需要添加新的需求到原始需求中，或者原始需求需要修改或缩减，那么这被视为一次需求变更。有效的变更管理需要评估变更的潜在影响和成本。这涉及维护清晰的需求说明、适用于每个需求类型的属性，以及与其他需求