作者简介作者简介：薛强（1986-），男，卡斯柯信号有限公司系统设计主管、工程师，研究方向为城市轨道交通信号系统架构设计。1需求定义及需求工程学概述
　　按照cmmi（能力成熟度集成），需求是指：①用户所需的用于解决一个问题或达成一个目标的条件或能力；②系统或系统元件必须满足或具有的条件或功能，以满足合同、标准、规格书或者其它正式附加文档的要求；③如①和②中文档描述的其它条件或能力。
　　按照软件工程学理论，需求工程是包括创建和维护系统需求文档所必需的一切活动的过程，可以分为需求开发和需求管理两大工作。①需求开发：包括需求获取、需求分析、编写需求规格书（需求矩阵）和需求验证4个阶段；②需求管理：通常包括定义需求基线、处理需求变更及需求跟踪等方面的工作。
　　 这两方面是相辅相成的，需求开发是主线，是目标；需求管理是支持，是保障。换句话说：需求开发应清晰、明确地掌握客户对系统的需求；而需求管理则是对需求变化进行管理的过程。
　　按照组织的成熟度等级，需要对需求进行不同级别的管理。在cmmi中，需求工程的要求与成熟度等级的对应关系见表1。
　　表1需求工程的要求与成熟度等级的对应关系过程域缩写类别成熟度等级需求开发rd工程管理3需求管理reqm项目管理22需求工程作用
　　本处以v生命周期为例，如图1，需求工程技术在城市轨道交通信号系统工程生命周期中的作用，贯穿在项目的整个生命周期中，对整个项目起到指导作用。
　　图1v生命周期
　　一方面需求对系统设计进行指引，使系统实现在需求的范围内；另一方面需求对实现的系统在交付运营前进一步验证，保证系统实现和需求的一致性。WwW.11665.cOM
　　3需求开发
　　在工程应用中，需求获取过程主要集中在招标、合同谈判、签订的合同中，这些统称为合同需求。
　　为了便于对需求进行追踪管理，首先需要对合同需求进行分析并编号（分配标签）。按照需求分析结果，并考虑实现形式的方便性，使用合适的需求管理工具建立需求技术规格书或者需求矩阵。
　　需求分析需要特别考虑需求特征。需求特征主要有：必要性、简要性、可行性、完整性、唯一性、一致性、明确性、可验证性，这些特征是需要能否成为一条独立的需求存在的基本特征，也是需求验证的指导原则。
　　鉴于需求特征的重要性，以下详细阐述需求特征:①必要性：即说明的需求必须为产品或过程的基本功能、物理特性或质量因素。如果该需求被删除将会造成缺陷，且此缺陷不能被该产品或过程的其它功能所弥补；②简要性：该需求说明只包括一个需求，即简单和清晰地说明必须做的事情，应易于阅读和理解。为简要起见，需求的表述不应包含任何解释、原理、定义或系统描述。需求用于描述需要什么，而不是如何满足；③可行性：通过一个或多个已开发系统计划，以预定的成本，描述需求能否实现；④完整性：所表述的需求是完整的，不需进一步扩展，并且能够提供足够的性能；⑤唯一性：同一个需求出现次数不应多于一次。重复本身不是错误，但很容易导致错误。重复有时会使一篇文档易于阅读，但是当对一篇包含重复需求的文档进行更新时就会出现问题。当必须出现重复需求时，文档应该包含明确的互相参照，以保证它的可修改性；⑥一致性：所表述的需求不能与其它需求相矛盾；⑦明确性：每项需求都必须有且只有一种解释。用于描述的文字在表述和数值上不能给读者留下疑惑，不能用“最少”和“最多”来表述限制，要用“不少于”或“不多于”。这样的标准表述，这是为了避免出现与限定值相关的不确定性。比如：需求“高度校正误差应不大于1.5毫弧度”的表述是清楚的，因为它明确了1.5毫弧度误差是允许的。另一方面，如果这个需求表述为“高度校正误差最大为1.5毫弧度”，那么对于1.5毫弧度这个限制值是否允许就很含糊。这条规则并不是说“最多”和“最少”这两个词完全不可以用，而只是在表述限制值时不要用。应避免使用的词语：一些特别的词语应该避免，因为它们的意思是含糊的，主要有“灵活的”、“故障容忍”、“高保真”、“能适应的”、“快速的”、“适当的”、“使用友好的”、“支持”、“最大”和“最小”、“和/或”、“等等”；⑧可验证性：所表述的需求是清晰具体的，是在某种意义上可量化的，并可通过检查、分析和测试来验证。
　　4需求管理
　　需求

管理包括的活动及任务见表2。
　　表2需求管理活动及任务
　　需求管理活动活动的任务需求跟踪定义对于其它需求及系统规格、架构、实现的联系，并跟踪需求的状态处理需求变更关注需求变更并分析其影响定义需求基线确定每个需求以及功能规格说明的版本需求跟踪至少要满足以下要求：①审核、跟踪信息，可以帮助审核，确保所有需求被覆盖；②在增加、删除、修改需求时可以确保不忽略每个受到影响的系统元素；③维护时能正确、完整地实施变更，从而提高生产效率；④获得当前实现状态的记录；⑤再工程，可以列出旧系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置；⑥重新利用跟踪信息，帮助开发人员在新系统中对相同的功能利用旧系统相关资源开发；⑦减少由于关键成员离开给项目组带来的风险；⑧可以在测试出错时指出最有可能出问题的数据或代码段。
　　为了实现以上要求，需求跟踪需要编制每个需求与系统元素之间的联系文档。这些元素包括已识别的需求、约束、其它设计部件、源代码模块、测试、帮助文件和文档等。
　　需求跟踪分为正向跟踪和逆向跟踪，一般合称为“双向跟踪”。正向追踪主要解决从需求到实现的过程，逆向追踪反之；同时，按照追踪的层次，有纵向追踪和横向追踪。纵向追踪用于实现分配到下级的需求都被标识、追踪、实现和验证，横向追踪用于确定同级需求的一致性。
　　不论采用何种跟踪方式，为了实现需求追踪的要求，都要建立与维护需求跟踪矩阵。需求跟踪矩阵的建立和维护方法很多，可以采用离线或在线工具，比如reqtify和doors等，也可以采用半自动化的形式化语言。因为reqtify工具的灵活性和开放性，在笔者公司的项目实践中被作为需求管理主流工具使用。
　　需求跟踪矩阵保存了需求与后续工作成果的对应关系，通过需求跟踪矩阵可以跟踪一个需求使用期限的全过程，即从需求源到实现乃至维护的全部生命周期。它跟踪的是已明确的需求实现过程，不涉及需求开发人员的职责，也无法用于防止变更矩阵单元之间可能存在的“一对一”、“一对多”或“多对多”的关系。由于对应关系比较复杂，最好在表格中加入必要的文字解释，或者在需求管理工具中加入图片、表格等进一步明确需求。要关注需求文档或后续工作成果，当其发生变更时，要及时更新需求跟踪矩阵。
　　需求管理的需求状态跟踪功能至少要满足以下要求：①能够查询出于某种状态的需求；②能够对需求状态进行统计，并支持图标显示和报表功能；③能够跟踪某一特定需求的状态改变。另外的一些附加功能，比如：能够查询到某一个特定需求的状态改变时间和执行状态、改变人员及其批注信息等。
　　每条需求有多个属性，如状态、优先级、创建时间、类型等。
　　需求状态按照预定义的工作流程进行定义和转变。需求的状态可能有：①capture：这条需求是新近获取并添加入需求文档中的；②verified：该条需求已被验证；③covered：该需求已经被覆盖；④tested：测试需求时能和最初需求定义一致；⑤na：该条需求因为不适用，已经被移除；⑥validated：需求已经实现并且被证明有效。
　　需求类型按照涉及的子系统进行定义，比如ats（自动监控子系统）、atc（自动列车控制子系统）、mms（微机监测子系统）、cbi（计算机联锁子系统）。