搜索
第一章软件需求缩略词CIA机密性，完整性，可用性DAG定向非循环图FSM功能规模度量INCOSE系统工程国际委员会UML统一建模语言SysML系统建模语言介绍软件需求知识领域(KA)涉及软件需求的引出、分析、说明和验证，以及软件产品整个生命周期中需求的管理。在研究人员和行业从业者中，人们普遍认为，当需求相关的活动表现不佳时，软件项目是非常脆弱的。软件需求表达了对软件产品的需求和约束，这些产品有助于解决一些实际问题。术语“需求工程”在这个领域被广泛使用，表明系统地处理要求。出于一致性的原因，“工程”这个词除了用于软件工程之外，不会被用于在KA中。出于同样的原因，“需求工程师”这一术语出现在一些文献中，也不会被使用。相反，术语“软件工程师”或某些特定情况下将使用“需求专家”，后者通常是由软件工程师以外的其他人扮演。但这并不意味着软件工程师无法执行该功能。一个固有风险被提议要分解：一个瀑布式的过程可以被推断出来。为了防范这一问题，主题2被设计为通过阐述流程运行的资源和限制因素以及确定流程的方式来提供需求流程的高级概述。另一种分解可以基于产品的结构(系统需求、软件需求、原型、用例等等)。基于过程的故障反映了这样一个事实:如果要成功，需求过程必须被看作是一个涉及复杂的、紧密耦合的活动(包括顺序和并发)的过程，而不是在软件开发项目开始时执行的离散的、一次性的活动。软件要求KA与软件设计，软件测试，软件维护，软件配置管理，软件工程管理，软件工程流程，软件工程模型和方法以及软件质量KA密切相关。软件需求主题的分解软件需求的主题的分解KA如图1.1所示。1.软件需求基本元素[1*,c4,c4s1,c10s1,c10s4][2*,c1,c6,c12]1.1软件需求的定义在最基本的情况下，软件需求是为了解决现实世界中的一些问题必须展现的一个属性。它的目的可能是使某些任务的一部分自动化，以支持组织的业务流程，纠正现有软件的缺陷或控制设备-仅列举可能的软件解决方案的许多问题中的一些。用户，业务流程和设备的功能通常很复杂。因此，通过扩展，对于特定软件的要求通常是来自组织的不同级别的各种人以及与软件将在其中运行的环境中涉及或与该特征相关联的人的复杂组合。软件需求软件需求基本原理需求过程需求获取需求分析需求规范需求验证实际问题软件需求模型软件需求的定义过程模型需求来源需求分类系统定义文件需求评审需求过程的迭代性质产品和过程需求过程参与者获取技巧概念建模系统需求规范原型设计变更管理功能和非功能需求过程支持和管理结构设计和需求分配软件需求规范模型验证需求属性应急属性过程质量和改进需求协商验收测试需求跟踪可量化的需求正式分析需求测量系统需求和软件需求图1.1软件需求的主题的分解KA所有软件要求的一个基本属性是，它们作为功能要求的单个功能可视为系统级别的非功能要求。验证某些软件需求可能是困难或昂贵的。例如，对呼叫中心的吞吐量要求的验证可能需要开发仿真软件。软件需求，软件测试和质量人员必须确保可以在可用的资源限制内验证该项目。除了行为属性之外，需求还有其他属性。常见的例子包括在有限资源面前实现权衡的优先等级，以及使项目进度得到监控的状态值。通常，软件需求被唯一识别，使得它们可以在特征和软件的整个生命周期中经受软件配置管理。1.2产品和过程需求产品需求是所开发的软件的一个需求或限制（例如，“该软件将在其注册课程之前验证学生满足所有先决条件”）。过程需求本质上是对软件开发的约束(例如，“软件应该使用RUP过程来开发”)。一些软件需求产生了隐式的过程需求。验证技术的选择就是一个例子。另一个可能是使用特别严格的分析技术（如正式指定方法）来减少可能导致可靠性不足的故障。过程要求也可由开发组织，其客户或第三方（如安全监管者）直接施加。1.3功能性和非功能性需求功能需求描述了软件执行的功能;例如，格式化一些文本或调制信号。它们有时被称为功能或特性。功能需求也可以被描述为一个可以编写有限的测试步骤来验证其行为的方法。非功能性需求是限制解决方案的需求。有时称为非功能性需求是约束或质量需求。它们可以根据性能需求，可维护性需求，安全需求，可靠性需求，互操作性需求或许多其它类型的软件需求之一进一步分类（参见软件质量KA中的型号和质量特性）。1.4应急属性一些需求代表了软件的应急特性，即不能由单个组件解决的需求，但这取决于所有的软件组件是如何互操作的。例如，呼叫中心的吞吐量要求取决于电话系统、信息系统和操作人员如何在实际操作条件下进行交互。应急属性非常依赖于系统体系结构。1.5可量化的需求软件需求应尽可能清楚明确地说明，并酌情定量说明。重要的是要避免模糊和不真实的需求，这些需求依赖于他们对主观判断的解释(“软件应该是可靠的”;“软件应该是用户友好的”)。这对于非功能性需求尤其重要。量化需求的两个例子如下：呼叫中心的软件必须将中心的吞吐量提高20％;并且系统在运行的任何一个小时内产生致命错误的概率应小于1*10-8。吞吐量需求处于非常高的水平，需要使用它来导出一些详细的要求。可靠性要求将严格限制系统架构。1.6系统需求和软件需求在这个主题中，“系统”是指要完成定义的目标的元素的相互作用的组合。这些包括由国际软件和系统工程理事会（INCOSE）[3]定义的硬件，软件，固件，人员，信息，技术，设施，服务和其他支持元素。系统需求是整个系统的需求。在包含软件组件的系统中，软件需求来自于系统需求。KA以限制的方式定义了“用户需求”，作为系统客户或最终用户的需求。相比之下，系统需求包括用户需求，其他利益相关者（如监管机构）的需求以及没有可识别人力资源的需求。2.需求过程[1*,c4s4][2*,c1–4,c6,c22,c23]本部分介绍软件需求过程，确定剩余的五个主题，并展示需求过程如何与整个软件工程流程相衔接。2.1流程模型该主题的目的是提供一种理解，即需求过程不是软件生命周期的离散前端活动，而是一个在整个生命周期中不断被重新设计的项目开始的过程;该主题的目的是提供一个理解，即需求过程将软件需求确定为配置项目，并使用与软件生命周期流程的其他产品相同的软件配置管理实践进行管理;该主题的目的是提供一种理解，即需求过程需要适应组织和项目环境。特别地，该主题涉及引导，分析，指定和验证的活动如何与不同类型的项目和约束相匹配。该主题还包括为需求过程提供投入的活动，如市场营销和可行性研究。2.2过程参与者本主题介绍参与需求过程的人员的角色。这个过程从根本上是跨学科的，需求专家需要在利益相关方的领域和软件工程的领域之间进行调解。除了需求专家以外，还有许多人参与其中，他们每个人都有软件的股份。利益相关者将根据不同的项目而有所不同，但总是包括用户/运营商和客户（不需要相同）。软件利益相关者的典型例子包括（但不限于）以下内容：用户：该组包括操作软件的人员。通常是涉及不同角色和要求的人的异质性群体。客户：该组包括委托软件或代表软件目标市场的人员。市场分析师:大众市场产品将不会有一个委托客户，因此市场营销人员通常需要建立市场需求，并充当代理客户。监管机构：银行和公共交通等许多应用领域受到监管。这些领域的软件必须符合监管机构的要求。软件工程师:这些人从开发软件的过程中获得了合理的利益，例如，重用其他产品的组件。如果在这种情况下，某个特定产品的客户有特定的需求，这可能会损害组件重用的潜力，那么软件工程师必须仔细权衡他们自己的利益和客户的利益。特定的需求，特别是约束，可能会对项目成本或交付产生重大影响，因为它们要么与工程师的技能组合很好，要么很差。应该确定这些需求之间的重要权衡。不可能完全满足每个利益相关者的要求，而且软件工程师的工作是协商主要利益相关者可以接受的折中方案，并且在预算，技术，监管和其他限制之内。这样做的先决条件是所有的利益相关者都被识别，他们的“利害关系”的性质被分析，并且他们的需求被引出。2.3过程支持与管理本节介绍需求过程所需和使用的项目管理资源。它为软件工程管理KA的第一个主题（起始和范围定义）建立了上下文。其主要目的是使2.1中识别的流程活动与成本，人力资源，培训和工具等问题联系起来。2.4过程质量和改进本课题涉及质量评估和需求流程改进。其目的是强调需求过程在软件产品的成本和及时性以及客户对其的满意度方面的关键作用。它将有助于将需求过程定位为软件和系统的质量标准和过程改进模型。过程质量和改进与软件质量KA和软件工程流程KA密切相关，包括流程改进标准和模式要求流程覆盖；需求过程度量和基准测试；改进规划和实施；安全/CIA改进/规划和实施。3.需求获取[1*,c4s5][2*,c5,c6,c9]需求获取涉及软件需求的来源以及软件工程师如何收集它们。了解软件需要解决的问题是它的第一阶段。这在根本上是一种人类活动，是利益攸关方的确定和开发团队与客户之间建立关系的地方。它被称为“需求捕获”，“需求发现”和“需求获取”。良好需求获取过程的基本原则之一是各利益攸关方之间有效沟通。在不同的时间点，不同的利益相关者通过整个软件开发生命周期（SDLC）流程进行这种沟通。在开发开始之前，需求专家可能会形成此通信的渠道。他们必须在软件用户（和其他利益相关者）的领域和软件工程师的技术世界之间进行调解。一系列内部一致的抽象层次模型促进了软件用户/利益相关者和软件工程师之间的沟通。需求获取的关键要素是通知项目范围。这涉及提供指定的软件的描述及其目的，并确定可交付成果的优先级，以确保客户最重要的业务需求得到满足。这最大限度地减少了需求专家花费时间引出低重要性的需求的风险，或者在软件交付时变得不再相关的风险。另一方面，描述必须是可扩展的和可扩展的，以接受在第一正式列表中未表达的进一步的需求，并且与递归方法中考虑的先前的需求兼容。3.1需求来源需求在典型软件中有许多来源，并且所有潜在的来源都必须被识别和评估。本主题旨在提高对各种软件需求来源的认识以及管理软件需求的框架。所涉及的要点如下：目标。术语“目标”（有时称为“业务关注”或“关键成功因素”）是指软件的整体、高层次目标。目标为软件提供了动力，但通常是含糊不明确的。软件工程师需要特别注意评估目标的价值（相对于优先级）和成本。可行性研究是一种相对较低成本的方法。领域知识。软件工程师需要获取或掌握有关应用领域的知识。领域知识提供了背景，为了理解这些知识，必须设置所有获取的需求知识。在知识领域中模仿本体论的方法是一个很好的做法。应确定应用领域相关概念之间的关系。利益相关者（见第2.2节，过程参与者）。许多软件已经被证明是不能令人满意的，因为它强调了一组利益相关者的需求，而牺牲了他人的需求。因此，交付的软件很难使用，或颠覆了客户组织的文化或政治结构。软件工程师需要识别，代表和管理许多不同类型的利益相关者的“观点”。业务规则。这些语句定义或约束了结构的某些方面或业务本身的行为。“如果有一些未支付的学费，学生就不能注册下学期的课程”将成为一个商业规则的例子，这将成为大学课程注册软件的一个要求来源。操作环境。需求将来自软件将被执行的环境。这些可能是例如实时软件中的时序限制或业务环境中的性能约束。这些必须积极寻求，因为它们可以极大地影响软件的可行性和成本，并限制设计选择。组织环境。通常需要软件来支持业务流程，其选择可能受组织结构，文化和内部政治的制约。软件工程师需要对这些敏感，因为一般来说，新软件不应该强制业务流程中的计划外变更。3.2获取技巧一旦需求来源被识别，软件工程师就可以开始从他们那里获取需求信息。请注意，需求很少能得到现成的。相反，软件工程师会从他或她制定需求的信息中获得信息。本课题集中在让人类利益相关者阐明需求相关信息的技术。这是一个非常困难的任务，软件工程师需要对这样一个事实敏感(例如)用户可能难以描述他们的任务，可能会留下重要的信息，或者可能不愿意或者不能合作。特别重要的是要明白，获取并不是一种被动的活动，即使可以合作并且有明确的利益相关者，软件工程师也必须努力获取正确的信息。许多业务或技术需求是默认的，或者是尚未从最终用户那里获得的反馈。规划，确认和验证在需求获取过程中的重要性