CN103246948A

CN103246948A - 需求管理的方法及装置

Info

Publication number: CN103246948A
Application number: CN2012100327137A
Authority: CN
Inventors: 何芸谷
Original assignee: Huawei Technologies Co Ltd
Current assignee: Honor Device Co Ltd
Priority date: 2012-02-14
Filing date: 2012-02-14
Publication date: 2013-08-14
Anticipated expiration: 2032-02-14
Also published as: CN103246948B; WO2013120338A1

Abstract

本发明实施例提供了一种需求管理的方法和装置。该方法主要包括：将系统的所有需求按照各个需求的服务的对象、价值和颗粒度划分成从上到下的各个层次；获取所述系统中任一个需求的直接进度；获取所述任一个需求的所有下级层次的需求的直接进度；对所述所有下级层次的需求的直接进度求平均值，得到所述任一个需求的验证进度，对所述任一个需求的直接进度和验证进度进行加权运算，得到所述任一个需求的进度。本发明实施例提供了一种全面的、高效的需求分层、分类方法，通过进行需求的业务分类的完备性检查，解决了现有技术大规模需求管理过程中需求不完备、跟踪有遗漏等问题，提高了需求管理和系统设计的质量和效率。

Description

需求管理的方法及装置

技术领域

本发明涉及计算机应用技术领域，尤其涉及一种需求管理方法及装置。

背景技术

随着电信和互联网的发展，各种软硬件系统越来越复杂，对系统的需求也越来越多样化，为了保证系统的高效率，需要对复杂的需求进行E2E(end toend，端到端)管理，确保需求是完备的并且在需求传递过程中不失真、不丢失。

从需求的完备性来讲，通常用户对产品的需求包括两类：一类是功能性需求，另一类是非功能性需求。产品的功能性需求，是指产品需要提供的功能；产品的非功能性需求，是指产品为满足用户业务需求而必须具有且除功能需求以外的特性，如性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。随着行业标准的发展与成熟，产品间的功能已同质化，随着技术的不断进步与普及，实现功能的关键技术的可获得性已不再是障碍；因此，产品间的竞争差异主要体现在非功能性方面的差异，而用户对非功能性方面的需求也越来越关注。在实际产品研发过程中，仅仅实现功能需求是不够的，也需要从专业的角度对需求进行划分和管理。业界各大运营商和设备商、供应商都有相应的需求分类管理方法，通常的方法为：DFX(Design for X(quality attribute，质量属性设计)分类方法。DFX在设计之初就开始系统考虑如何实现有竞争力的非功能需求的属性，提升产品质量与竞争力。现有的DFX分类如下述表1所示：

上述DFX分类方法中的类别非常多而且零散，相互直接的关系也无法识别，直接采用上述DFX分类方法来进行非功能性需求的质量属性的管理和设计，效率非常低下，需求完备性也难以保证。

发明内容

本发明的实施例提供了一种需求管理的方法及装置，来管理系统的需求，以解决大规模需求管理过程中需求不完备、需求管理效率低下的问题。

一种需求管理方法，包括：

将系统的所有需求按照各个需求的服务的对象、价值和颗粒度划分成从上到下的各个层次；

获取所述系统中任一个需求的直接进度，所述直接进度是与所述任一个需求直接关联的测试用例测出的进度；

获取所述任一个需求的所有下级层次的需求中每个需求的直接进度，所述每个需求的直接进度，是与所述每个需求直接关联的测试用例测出的进度；

对所述所有下级层次的需求的直接进度求平均值，得到所述任一个需求的验证进度，对所述任一个需求的直接进度和验证进度进行加权运算，得到所述任一个需求的进度。

本发明实施例还提供一种需求管理装置，包括：

需求划分模块，用于将系统的所有需求按照各个需求的服务的对象、价值和颗粒度划分成从上到下的各个层次；

第一直接进度获取模块，用于获取与所述系统中任一个需求的直接进度，所述直接进度是与所述任一个需求直接关联的测试用例测出的进度；

第二直接进度获取模块，用于获取所述任一个需求的所有下级层次的需求中每个需求的直接进度，所述每个需求的直接进度，是与所述每个需求直接关联的测试用例测出的进度；

需求进度获取模块，用于对所述所有下级层次的需求的直接进度求平均值，得到所述任一个需求的验证进度，对所述任一个需求的直接进度和验证进度进行加权运算，得到所述系统中任一个需求的进度。

本发明实施例通过以上技术方案，将系统的所有需求按照各个需求的服务的对象、价值和颗粒度划分成从上到下的各个层次，从而能够根据低层次的需求的进度自动计算出高层次的需求的进度，通过将分层管理和进度运算相结合，使得复杂系统的需求跟踪和管理变得方便和有序，降低管理成本。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1为本发明实施例一提供的一种需求管理的方法的处理流程图；

图2为本发明实施例一提供的一种对需求进行分层处理的原理示意图；

图3为本发明实施例一提供的一种DFX业务分类分层架构的示意图；

图4为采用需求记录中一个属性字段来表达三个层次的业务分类的架构的示意图；

图5为采用需求记录中多个属性字段来表达三个层次的业务分类的架构的示意图；

图6为本发明实施例二提供的一种需求管理的装置的具体结构图。

具体实施方式

为便于对本发明实施例的理解，下面将结合附图以几个具体实施例为例做进一步的解释说明，且各个实施例并不构成对本发明实施例的限定。

实施例一

为了便于不同角色的协同和需求的逐步明晰，通常将需求进行分层管理，通过需求的层层分解和传递达到最终实现用户需求的目的。

本发明实施例提供一种需求管理方法，如图1所示，该方法包括如下的处理步骤：

步骤11、将系统的所有需求按照各个需求的服务的对象、价值和颗粒度划分成从上到下的各个层次。

本发明实施例提供的一种对需求进行分层处理的原理示意图如图2所示，根据各个需求的服务的对象、价值和颗粒度，将系统的所有需求划分为从上到下的4个层次：PB(用户问题)层、SF(系统特性)层、SR((系统需求)层和AR(分配需求)层，其中，PB层是最高层，SF层隶属于PB层，SR层隶属于SF层，AR层隶属于SR层。PB、SF、SR、AR体现了需求的逐层分解细化，且从上到下需求之间具有跟踪关系，部分层级需求会独立测试。

PB层是体现用户业务的特别关注点的需求，SF层是系统提供的解决用户问题的重大价值的需求，SR层是系统对外提供的全部功能和非功能需求，AR层是系统需求分解分配到子系统/模块层次的需求。本发明实施例所述的RR、PB、SF、SR、AR等是需求不同层次的名称，实际应用和实现时可以不一定就叫这些名称，可以用L1、L2、...、Ln等抽象名称代替。

需要说明的是，本发明所有实施例所述的系统指的是待研究和待开发、交付、销售的对象，具有相对的含义，可以是一个解决方案、一个具体的产品(网元)或者是一个单独交付的平台。

对于测试验证而言，系统级别的测试验证主要针对的是SR层次的需求，而单元级别的测试验证主要针对的是AR层级的需求，另外用户的验收测试一般针对的是SF层级的需求。

步骤12、获取所述系统中任一个需求的直接进度，所述直接进度是与所述任一个需求直接关联的测试用例测出的进度。

本发明实施例提出了上述系统中任一个需求的进度的概念，需求的进度体现了需求的测试进展。

上述系统中任一个需求的进度包括：直接进度和验证进度，所述直接进度是与所述任一个需求直接关联的测试用例测出的进度，如图2所示，每一层的需求都关联了一个测试用例(如图2中的SF TC、SR TC、AR TC)，用于测试各个需求的完成情况，即直接进度；基于与需求直接关联的测试用例的运行情况，就可以该需求的直接进度；验证进度是根据任一个需求的所有下级层次的需求的直接进度，求平均值得出的进度，直接进度和验证进度在一定程度上都能体现一个需求的完成情况，但都不完全准确。

步骤13、获取所述任一个需求的所有下级层次的需求中每个需求的直接进度；

具体地，可以通过获取与所述系统中任一个需求的所有下级层次的需求中的每个需求直接关联的测试用例的运行情况，基于所述运行情况确定所述任一个需求的所有下级层次的需求中的每个需求的直接进度。

步骤14、对所述所有下级层次的需求的直接进度求平均值，得到所述任一个需求的验证进度，对所述任一个需求的直接进度和验证进度进行加权运算，得到所述任一个需求的进度。

验证进度表示所述任一个需求的所有下级层次的需求的直接进度的测试进展的综合结果。将所述所有下级层次的需求的直接进度求平均值得到所述任一个需求的验证进度，对所述任一个需求的直接进度和验证进度按照对应的权重进行加权运算，得到所述任一个需求的进度。

需要说明的是，直接进度和验证进度在一定程度上都能体现一个需求的完成情况，但都不完全准确，并不是最理想的形式，有鉴于此，本发明实施例通过对直接进度和验证进度进行加权运算，来更准确地得出一个需求的进度。

具体地，在一个实施例中，设Lm层的需求F包括n个下级层次的需求F1～Fn，比如，上述Lm层的需求F为SF1，SF1包括n个SR(SR1～SRn)。

根据公式：F_验证进度＝(F1_进度+...+Fn_进度)/n，计算所述需求F的验证进度F_验证进度；

根据公式：F_进度＝F_直接进度＊X+F_验证进度＊(1-X)，计算所述需求F的进度F_进度；

其中，F_直接进度为与所述需求F直接关联的测试用例测出的所述需求F的直接进度，所述F1_进度为所述需求F1的直接进度，所述Fn_进度为所述需求Fn的直接进度，其中X为SF1的直接验证进度参与计算的权重，取值为0＜＝X＜＝1，在一个实施例中，可以设定X为0.9，在另一个实施例中，也可以设定X为0.8。

具体地，在需求管理工具上可以采用两个属性/字段来记录每条需求的进展，比如这两个字段名称为：验证进度、直接验证进度，验证进度字段用于保存该需求最终计算出来的进度(如上面的F_进度)，直接验证进度字段用于保存该需求通过测试系统直接关联该需求的测试用例反馈的进度字段(如上面的F_直接进度)，当下层需求进度计算完后，会自动触发上层需求进度的计算，直到最顶层。

由于上层需求分解的下层需求很多，调整也可能比较频繁，如果直接用上面的公式计算，即时性会比较差，因此进一步对该公式进行演进，采用增量计算方法，具体如下：

每条需求增加两个属性：进度旧值、直接进度旧值，用来记录进度和直接进度上一次变化后的值。具体的计算需求进度的方法为：

(1)如果需求F的下层需求(以F1为例)的直接进度发生变化，则先根据公式：F1_进度＝F1_进度旧值+(F1_直接进度-F1_直接进度旧值)＊Y，计算F1的进度F1_进度；然后再根据公式：F_进度＝F_进度旧值+(F1_进度-F1_进度旧值)＊(1-X)/n，计算出所述需求F的进度F_进度；

其中，F1_进度旧值为变化前的F1的进度，F1_直接进度新值为变化后的F1的直接进度，F1_直接进度旧值为变化前F1的直接进度，Y为设定的权重，取值为0＜＝Y＜＝1，F_进度旧值为下层需求F1变化前F的进度；

(2)如果需求F的下级层次的需求的个数从n个增加到m个，则根据公式：F_进度＝(n＊F_进度旧值+(m-n)＊F_直接进度＊X+(F(n+1)_进度+...+Fm_进度)＊(1-X))/m，计算变化后的F_进度，其中，其中F_进度旧值为下级层次的需求数目变化前的F的直接进度，F_直接进度为下级层次的需求变化后的F的直接进度，(F(n+1)_进度+...+Fm_进度)表示对F的所有下级层次的需求中，第n+1个需求到第m个需求的进度累加求和；

(3)如果需求F的下级层次的需求的个数从n个减少到k个，根据公式：F_进度＝(-n＊F_进度旧值+(n-k)＊F_直接进度＊X+(F(k+1)_进度+...+Fn_进度)＊(1-X))/(-k)，计算变化后的F_进度。

进一步地，如图3所示，所述的步骤11中还包括：根据系统从设计、开发、交付用户、用户使用系统、根据用户反馈对系统进行改进的全生命周期，将所述各个层次的需求的非功能属性划分成三个业务分类：产品交付类、产品运行类和产品演进类，并且所述系统的各个层次的所有需求包括所述不同的业务分类中的所有业务分类。

需要说明的是，系统的非功能性需求，是指系统为满足用户业务需求而必须具有且除功能需求以外的特性。系统的非功能性需求包括系统的性能、可靠性、可维护性、可扩充性和对技术和对业务的适应性等。在这里可以看到非功能性需求涉及的范围很广，系统本身不是孤立存在的，还涉及到诸多外在环境的影响。非功能性需求必须考虑系统既要可用，又要易用。

其中，产品交付类表示从系统完成开发到将系统交付给用户的过程中产生的需求，产品运行类表示系统交付给用户后，进入运行维护的过程中产生的需求，产品演进类表示系统在修正错误、功能升级，产品演进的过程中产生的需求。具体地，产品产品交付类需求用于提升端到端(投标、计划预测、采购、成套、制造、包装发运、安装/调测/验收)交付效率和质量，缩短交付时间、提升库存周转率，降低采购、制造、交付和部署成本；产品运行类需求用于在产品运行期间确保全面满足用户的运行与维护要求，包括减少故障发生，降低故障发生的影响，故障发生后能尽快恢复，最大限度地减少资产和资源的脆弱性，提高产品生命周期内的资源使用效率、减少对环境的影响，同时提升产品服务的有效性、效率；产品演进类需求用于满足系统对现在和将来的不同场景和需求的灵活应对能力，包括特性/功能的增减、容量和性能的伸缩、技术的演进、平台的迁移等。

进一步地，如图3所示，上述的三个业务分类还可以细分成更多层的业务小类：

产品交付类包括的业务小类有：可采购性(Procurement)类、可供应性(Supply Chain)类、可部署性(Deployment)类；

产品运行类包括的业务小类有：可靠性(含可测试性)(Reliability)类、性能(Performance)类、可服务性(Serviceability)类、节能减排(EnergyEfficiency and Environment)类、安全性(Security)类、兼容性(Compatibility)类；

产品演进类包括的业务小类有：灵活性(Flexibility)类、可迁移/移植性(Portability)类、可重用性(Reusability)类；

进一步地，上述业务小类还可以细分为更小的业务子类：简洁化设计(Design for Simplicity)类、可变性设计(Design for Variety)类、延迟性设计(Design for Postponement)类、可制造性设计(Design for Manufacturability)类、可装配性设计(Design for Assembly)类、物流设计(Design for Logistics)类、可用性设计(Design for Availability)类、可诊断性设计(Design fordiagnosis)类、可测试性设计(Design for Testability)类、可维修性设计(Design for Repair)类、人身安全设计(Design for Safety)类、可维护性设计(Design for Maintainability)类、国际化设计(Design for Globalization)类、易用性设计(Design for Usability)类、能效设计(Design for Energy Efficiency)类、环境设计(Design for Environment)类、互操作性设计(Design forinteroperability)类、顺从性设计(Design for Compliance)类、可伸缩性设计(Design for Scalability)类、可扩展性设计(Design for Extensibility)类。

上述各业务分类以及业务小类和业务子类包含的具体分类名称可以根据业务发展情况而有增加、减少和更名的调整。

上述多个层次的业务分类构成了系统的解决方案DFX非功能属性层次框架，建立了系统的全生命周期DFX属性模型。在需求管理和设计工具中，采用需求记录中一个或多个属性字段来表达和维护这种系统的需求的三层分类架构。

比如，如图4所示，采用一个属性字段的方式：例如叫业务分类，包含层级选项来表示上述三层分类架构。

又比如，如图5所示，多个属性字段的方式：用3个字段表达，例如叫业务大类、业务小类、业务子类，其中

业务大类包含上述三个业务分类：产品交付类、产品运行类、产品演进类；

业务小类为上述三个业务分类细分后的业务小类：可采购性等

业务子类为上述业务小类继续细分成的业务子类：简洁化设计等

根据上述一个或多个属性字段来进行需求的业务分类的完备性检查，即检查系统的需求是否包括了上述三个业务大类中所有业务分类。

比如，一个系统包括5个需求，分别属于PB、SF或SR层，上述三个层次的业务分类只使用第一层次的产品交付类、产品运行类、产品演进类3个业务种类，则上述5个需求中的每个需求属于产品交付类、产品运行类或者产品演进类，并且，上述5个需求必须包括所述产品交付类、产品运行类、产品演进类3个业务种类。

当使用上述三个层次的所有业务分类时，系统将通过工具或报表等形式，对所述系统的所有需求中的各个需求的完备性进行检查，如果所述系统的所有需求的非功能属性没有包括所述各个层次的业务分类中的所有业务分类，则发出所述系统的完备性检查不通过的提示信息给系统管理人员，以指示所述系统的需求的完备性检查不通过。以使得系统管理人员对上述系统的需求进行补充，使得所述系统的所有需求的非功能属性包括所述各个层次的业务分类中的所有业务分类。

进一步地，用户不仅关心需求的测试进展，还关心需求的E2E进展，想知道当前需求具体处在什么阶段。

在本发明实施例中，当需求的分析完成时，需求的E2E进度为20％；

当需求的设计完成时，需求的E2E进度为40％；

当需求的开发(对于软件而言是编码)完成，需求的E2E进度为70％，开发过程中则E2E进度为40～70％之间；

当需求的测试验证完成，需求的E2E进度为100％，测试过程中则E2E进度为70～100％之间；

上述20％、40％、70％等具体数值只是示例，实际应用和实现可根据情况调整设置。

本发明实施例通过以上技术方案，提供了一种全面的、高效的需求分层、分类方法，解决了现有的上述DFX分类方法中的类别非常多而且零散，相互直接的关系也无法识别的问题，提高了需求管理和系统设计的质量和效率。

本发明实施例通过进行需求的业务分类的完备性检查，对待开发的系统或产品的范围在产品全生命周期过程中能够更好地得到定义和交付，解决了现有技术大规模需求管理过程中需求不完备、跟踪有遗漏等问题。

本发明实施例能够根据低层次的需求的进度自动计算出高层次的需求的进度，通过分层管理和进度运算相结合，使得复杂系统的需求跟踪和管理变得方便和有序，降低管理成本。

实施例二

该实施例提供了一种需求管理装置，其具体结构如图6所示，包括如下的模块：

需求划分模块61，用于将系统的所有需求按照各个需求的服务的对象、价值和颗粒度划分成从上到下的各个层次；

具体的，需求划分模块61，具体用于，将系统的所有需求划分为从上到下的4个层次：用户问题PB层、系统特性SF层、系统需求SR层和分配需求AR层，其中，PB层是最高层，SF层隶属于PB层，SR层隶属于SF层，AR层隶属于SR层，所述PB层是体现用户业务的特别关注点的需求，所述SF层是系统提供的解决用户问题的重大价值的需求，所述SR层是系统对外提供的全部功能和非功能需求，所述AR层是系统需求分解分配到子系统或模块层次的需求。

第一直接进度获取模块62，用于获取与所述系统中任一个需求的直接进度，所述直接进度是与所述任一个需求直接关联的测试用例测出的进度；

第二直接进度获取模块63，用于获取所述任一个需求的所有下级层次的需求的直接进度；

需求进度获取模块64，用于对所述所有下级层次的需求的直接进度求平均值，得到所述任一个需求的验证进度，对所述任一个需求的直接进度和验证进度进行加权运算，得到所述系统中任一个需求的进度。

具体的，需求进度获取模块64的工作过程可以参照本发明实施例一中的步骤14，此处不再赘述。

进一步地，该装置还可以包括：需求分类模块65，用于根据系统的全生命周期将所述各个层次的需求的非功能属性划分成三个业务分类：产品交付类、产品运行类和产品演进类，并且所述系统的各个层次的所有需求包括所述不同的业务分类中的所有业务分类。

进一步地，如图6所示，本发明实施例提供的需求管理装置还可以包括：需求完备性检查模块66，用于对所述系统的所有需求中的每个需求的完备性进行检查，如果所述系统的所有需求的非功能属性没有包括所述各个业务分类中的所有业务分类，则发出提示信息，以指示所述系统的需求的完备性检查不通过。

应用本发明实施例的装置进行需求管理的具体处理过程和上述方法的处理过程相同，在此不再赘述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，所述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。

综上所述，本发明实施例提供了一种全面的、高效的需求分层、分类方法，解决了现有的上述DFX分类方法中的类别非常多而且零散，相互直接的关系也无法识别的问题。通过需求分层、分类的机制完成E2E需求管理的过程，提高了需求管理和系统设计的质量和效率。

本发明实施例通过进行需求的业务分类的完备性检查，对待开发的系统或产品的范围在产品全生命周期过程中能够更好地得到定义和交付，解决了现有技术大规模需求管理过程中需求不完备、跟踪有遗漏等问题，更加满足客户的全方位需要，提高产品的竞争力。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims

1.一种需求管理方法，其特征在于，包括：

2.如权利要求1所述的需求管理的方法，其特征在于，所述将系统的所有需求按照各个需求的服务的对象、价值和颗粒度划分成从上到下的各个层次，具体包括：

将系统的所有需求分成4个层次：用户问题PB层、系统特性SF层、系统需求SR层和分配需求AR层，其中，PB层是最高层，SF层隶属于PB层，SR层隶属于SF层，AR层隶属于SR层；所述PB层是体现用户业务的特别关注点的需求，所述SF层是系统提供的解决用户问题的重大价值的需求，所述SR层是系统对外提供的全部功能和非功能需求，所述AR层是系统需求分解分配到子系统或模块层次的需求。

3.如权利要求1或2所述的需求管理的方法，其特征在于，在将系统的所有需求按照各个需求的服务的对象、价值和颗粒度划分成从上到下的各个层次之后，还包括：

根据系统的全生命周期将所述各个层次的需求的非功能属性划分成三个业务分类：产品交付类、产品运行类和产品演进类，其中，产品交付类表示从系统完成开发到将系统交付给用户的过程中产生的需求，产品运行类表示系统交付给用户后，进入运行维护的过程中产生的需求，产品演进类表示系统在修正错误、功能升级、产品演进的过程中产生的需求；

所述各个层次的需求中的每一个需求对应所述三个业务分类中的一个业务分类，所述系统的各个层次的所有需求包括所述不同的业务分类中的所有业务分类。

4.如权利要求3所述的需求管理的方法，其特征在于，在将所述各个层次的需求的非功能属性划分成三个层次的业务分类后，还包括：

对所述系统的所有需求中的各个需求的完备性进行检查，如果所述系统的所有需求的非功能属性没有包括所述三个层次的业务分类中的所有业务分类，则发出提示信息，以指示所述系统的需求的完备性检查不通过。

5.如权利要求1至4任一项所述的需求管理的方法，其特征在于，所述对所述所有下级层次的个需求的直接进度求平均值，得到所述任一个需求的验证进度，对所述任一个需求的直接进度和验证进度进行加权运算，得到所述任一个需求的进度，具体包括：

根据公式：

计算所述任一个需求F的验证进度F_验证进度；

根据公式：F_进度＝F_直接进度＊X+F_验证进度＊(1-X)，计算所述任一个需求F的进度F_进度；

其中，n为所述任一个需求F的所有下级层次的需求的个数，F_i为所述任一个需求F的所有下级层次的需求中第i个需求，F_直接进度为与F直接关联的测试用例测出的F的直接进度，F_i_进度为F_i的直接进度，X为设定的权重，取值为0＜＝X＜＝1。

6.如权利要求5所述的需求管理的方法，其特征在于，还包括：

当所述任一个需求F的下层需求F₁的直接进度发生变化后，则根据公式：F₁_进度＝F₁_进度旧值+(F₁_直接进度新值-F₁_直接进度旧值)＊Y，计算F₁的进度F₁_进度，

根据公式：F_进度＝F_进度旧值+(F₁_进度_F₁_进度旧值)＊(1-X)/n，计算出所述任一个需求F的进度F_进度，

其中，F₁_进度旧值为变化前的F₁的进度，F₁_直接进度新值为变化后的F₁的直接进度，F₁_直接进度旧值为变化前F₁的直接进度，Y为设定的权重，取值为0＜＝Y＜＝1，F_进度旧值为下层需求F₁变化前F的进度；

或者，当所述任一个需求F的下级层次的需求的个数从n个增加到m个时，根据公式：

计算下级层次的需求数目变化后的F的进度F_进度，其中F_进度旧值为下级层次的需求数目变化前的F的直接进度，F_直接进度为下级层次的需求变化后的F的直接进度，F_i_进度为所述任一个需求F的所有下级层次的需求中第i个需求的进度；

或者，当所述需求F的下级层次的需求的个数从n个减少到k个时，根据公式：

计算下级层次的需求数目变化后的F的进度F_进度。

7.一种需求管理装置，其特征在于，包括：

8.如权利要求7所述的需求管理装置，其特征在于：

所述的需求划分模块，具体用于，将系统的所有需求划分为4个层次：用户问题PB层、系统特性SF层、系统需求SR层和分配需求AR层，其中，PB层是最高层，SF层隶属于PB层，SR层隶属于SF层，AR层隶属于SR层，所述PB层是体现用户业务的特别关注点的需求，所述SF层是系统提供的解决用户问题的重大价值的需求，所述SR层是系统对外提供的全部功能和非功能需求，所述AR层是系统需求分解分配到子系统或模块层次的需求。

9.如权利要求7或8所述的需求管理装置，其特征在于，还包括：

需求分类模块，用于根据系统的全生命周期将所述各个层次的需求的非功能属性划分成三个业务分类：产品交付类、产品运行类和产品演进类，其中，产品交付类表示从系统完成开发到将系统交付给用户的过程中产生的需求，产品运行类表示系统交付给用户后，进入运行维护的过程中产生的需求，产品演进类表示系统在修正错误、功能升级、产品演进的过程中产生的需求；

所述各个层次的需求中的每一个需求对应所述不同的业务分类中的一个业务分类，所述系统的各个层次的所有需求包括所述不同的业务分类中的所有业务分类。

10.如权利要求9所述的需求管理装置，其特征在于，还包括：

需求完备性检查模块，用于对所述系统的所有需求中的每个需求的完备性进行检查，如果所述系统的所有需求的非功能属性没有包括所述各个层次的业务分类中的所有业务分类，则发出提示信息，以指示所述系统的需求的完备性检查不通过。

11.如权利要求7至10任一项所述的需求管理装置，其特征在于：

所述的需求进度获取模块，具体用于，根据公式：

计算所述任一个需求F的验证进度F_验证进度；

12.如权利要求11所述的需求管理装置，其特征在于：

所述的需求进度获取模块，还用于当所述任一个需求F的下层需求F₁的直接进度发生变化后，则根据公式：F₁_进度＝F₁_进度旧值+(F₁_直接进度新值-F₁_直接进度旧值)＊Y，计算F₁的进度F₁_进度，

根据公式：F_进度＝F_进度旧值+(F₁_进度-F₁_进度旧值)＊(1-X)/n，计算出所述任一个需求F的进度F_进度，

计算下级层次的需求数目变化后的F的进度F_进度，其中F_进度旧值为下级层次的需求数目变化前的F的直接进度，F_直接进度为下级层次的需求变化后的F的直接进度；

或者，当所述需求F的下级层次的需求的个数从n个减少到k个时，根据公式：计算下级层次的需求数目变化后的F的进度F_进度。