论文部分内容阅读
摘要：随着信息和网络通信技术的高速发展，电网企业为了提高需求管理实用化程度，加强和规范信息需求管理工作，针对各系统制定需求管理流程和标准并统一规范。本文主要介绍和分析多维度的需求分类及评审方法。
关键词：功能需求；非功能需求；评审方法
中图分类号：F014.32文献标识码： A 文章编号：
研究背景
现阶段广东电网公司信息系统需求管理总体内容在可管控范围之内，针对具体的需求仍需进行全程管理和跟踪。各个系统需求管理流程和方式各不相同，未制定统一需求管理标准。需求管理实用化程度相对来说较低，人员工作量繁重，重复工作比较多，影响人力资源的使用。对于需求管理信息中心各管理部门未明确管理职责，需统一全面管控。为加强和规范信息需求管理工作、有效落实需求管理全过程闭环机制，公司应针对各系统制定需求管理流程和标准并统一规范。
目前，电网公司正在进行一体化信息系统建设，广东电网也正在进行各种大集中系统的规划和建设，为了能够使大集中系统在建设过程中，避免需求不可控，需求管理不规范的情况，需要设计基于大集中系统的需求管控体系。本文主要对多维度的需求分类以及评审方法进行具体分析说明。
目标和意义
需求分析是一个非常重要的过程，它完成的好坏直接影响后续软件开发的质量。一般情况下，用户并不熟悉计算机的相关知识，而软件开发人员对相关的业务领域也不甚了解，用户与开发人员之间对同一问题理解的差异和习惯用语的不同往往会为需求分析带来很大的困难。因此，在需求分析阶段，能够清晰的描述和组建多维度的需求分类对软件开发至关重要。而需求评审不但是软件开发活动中一个重要的质量控制机制，而且也是一个重要而有效的沟通方式。通过评审可以尽早发现潜在的问题，尽早纠正缺陷，控制纠正成本的滚雪球效应。
需求分类
在一般使用中，需求按照功能性（行为的）和非功能性（其它所有的行为）来分类。
功能需求
功能需求定义了开发人员必须实现的软件功能，它源于用户需求。功能需求是软件需求说明书中最重要的部分之一，它在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。
需求分析人员理解用户需求，并编写需求规格说明书，对功能的输入、行为、输出进行组合及描述。作为后续设计工作和软件开发工作的最重要依据。
对于功能需求而言，最关键的地方是如何对其进行組织，保证开发人员能够理解在产品中需要实现的软件功能，确保用户利用这些功能来完成任务，满足业务需求。
在需求分析过程中，整理功能需求不是一项一蹴而就的工作，它需要一个长期的过程，而这个过程是一个由粗到细的过程，它体现了人类认识事物的客观规律。在需求分析的初期，我们对需求的认识往往是整体的、宏观的，随着分析工作的逐渐深入，一步步细化。
产品特性，是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并 帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。
功能需求除了来自于用户需求，还来自于其它几方面需求。
系统需求
用于描述包含多个子系统的产品(即系统)的顶级需求，它是从系统实现的角度描述的需求，有时还需要考虑相关的硬件、环境方面的需求。
业务规则
业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。它包括企业方针、政府条例、工业标准、会计准则和计算方法等。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。
质量属性
产品必须具备的属性或品质。系统的质量属性包括可用性、可修改、性能、安全性、可测试行以及易用性等
约束
约束也称为限制条件、补充规约，通常是对解决方案的一些约束说明。
2、非功能需求
非功能需求对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括功能性、可靠性、易用性、效率、维护性以及可移植性。
功能性
功能性指与一组功能及其指定的性质有关的一组属性，这里的功能是指满足明确或者隐含的需求的那些功能。具体包括：
适合性：与规定任务能否提供一组功能，以及这组功能的适合程度有关的软件属性，例如面向任务系统中由子功能构成的功能是否合适，表容量是否合适等等。
准确性：与能否得到正确或者相符的结果或者效果有关的软件属性。
互操作性：与其他指定系统进行交互的能力有关的软件属性。
依从性：使软件遵循有关的标准约定法规及类似规定的软件属性。
安全性：即与防止对程序技术局的非授权的故意或者意外访问的能力有关的软件属性。如用户权限、动态口令、数据库字段加密等。
对于这组非功能需求来说，绝大部分是满足功能需求的情况，他并不需要采用额外的措施，而安全性是一个例外，它会涉及具体的技术性功能需求。
可靠性
可靠性之与在规定的一段时间和条件下软件维持其性能水平的能力有关的一组属性。具体包括：
成熟性：与有软件故障引起失效的频度有关的软件属性。
容错性：与在软件故障或违反指定接口的情况下维持规定的性能水平的能力有关的软件属性。如离线录入支持等。
易恢复性：与在是小发生后重建其性能水平并恢复直接受影响数据的能力，以及为达到此目的所需时间和努力有关的软件属性。如表单数据自动保存等。
这类非功能需求通常是全局的，他除了与系统运行环境、平台选择、代码质量相关之外，还会涉及部分技术性功能需求，他别是容错性、易恢复性的实现都需要一些具体的功能来支持。
易用性
易用性是与一组规定或者潜在的用户为使用其软件所需做的努力和对这样的使用所作的评价有关的一组属性。具体包括：
易理解性：与用户为人质逻辑概念即其应用范围所花的努力有关的软件属性。
易学习性：与用户为学习软件应用所花的努力有关的软件属性。
易操作性：与用户为操作和运行控制所花的努力有关的软件属性。如带首字母筛选功能的下拉列表等。
这类非功能需求是与UI设计、联机帮助系统有着直接关系的，易理解性和易学习性通常和界面导航、联机帮助有关，课归纳为界面友好性；易操作性则会和界面元素设计有关。也就是说这类属性会关联到具体的技术性功能需求。
效率
效率是指与在规定的条件下软件的性能水平与所使用资源量有关的一组属性。具体如下：
时间特性：与软件执行器功能时响应和处理时间及吞吐量有关的软件属性。如数据缓存等。
资源特性：与在软件执行其功能时所使用的资源数量及其使用时间有关的软件属性。如数据压缩等。
这部分实际上就是通常所说的性能需求，他有一大部分是局部性的，在每个用力的描述中应该指出；另外它又会引申出一些相关的技术性功能需求，例如数据缓存等。
维护性
维护性是指与进行指定的修改所需的努力有关的一组属性。具体包括：
易分析性：与为诊断缺陷或者失效原因及为判定待修改的部分所需努力有关的软件属性。如日志记录系统等。
易改变性：与进行修改排除错误或者适应环境变化所需努力有关的软件属性。
稳定性：与修改所造成的未预料结果的风险有关的软件属性。
易测试性：与确认已修改软件所需的努力有关的软件属性。
这部分通常是开发团队最容易投入时间和成本的地方，诸如动态属性支持、UI界面生成、流程引擎等都是为了提高系统的可维护性，因此它显然是会引申出相关的技术性功能需求的。
可移植性
可移植性是指与软件可从某一环境转移到另一环境的能力有关的一组属性。具体包括：
适应性：与软件无需采用有别于为该软件准备的活动和手段就可能适应不同的规定环境有关的软件属性。如全球技术支持等。
易安装性：与在指定的环境下安装软件所需努力有关的软件属性。如在线更新、安装包自动生成等。
遵循性：使软件遵循与可移植性有关的标准或约定的软件属性。
可替换性：与软件在该环境中用来替代指定的其他软件的机会和努力有关的软件属性。
评审方法
在软件开发过程中，需求分析是最开始的工作，需求分析如果做得不够详细或者是偏离用户需求的话，往往会给项目带来灭绝性的灾难。因此如何保证需求分析的正确性，不偏离用户的需求就成了决定软件项目成败的关键。通常需求评审是用来检查需求正确性最有利的手段。
評审的过程不仅是为了发现问题，而且为了便于跟踪及改正，并且对问题进行记录。特别是需要对问题的真实性进行确认，剔除可能是误解、似是而非或不必采纳的建议性问题。
做好评审前的沟通和准备
需求编写人员应将评审所需的资料准备齐全，数据、图表、其他相关资料等，并仔细检查以保证文档质量。
需求文档在评审会议前应提前下发给参与评审会议的人员，并留出时间让参与评审的人员阅读需求文档。
参加评审的人，应该是带着问题而来，而不是来参加培训的。
先沟通好目标，再进行细节的落实。
应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。
分阶段评审保证了需求在形成的过程中不偏离方向，不出现大的错误，降低了需求返工的风险，提高了最终评审的质量。
正式评审与非正式评审相结合
正式评审：是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。
非正式的评审：通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。
两种形式各有利弊，因此在评审时，根据项目复杂程度，紧急程度不同而灵活运用。
评审角色构成
正式评审组的成员一般由用户代表，与项目经理、需求分析员、系统架构师、设计人员、测试人员、QA经理、记录人员以及公司相关领导参加。
需求评审流程
图1 需求评审流程图
评审结论
评审结论包括如下内容：
是否需要修改？这是就成果的整体而言，结论可以是无需、少量、较大或是一个量化的数字。
项目组确定是否接受修改要求？这是针对具体的一条意见或建议。有些问题可能是误会，消除了就不是问题；有些建议性的问题，项目组考虑进度可不接受修改要求。
如不接受修改要求，项目组给出不修改的理由。
如何处理？是否需要进行回归评审？
总体结论：合格或不合格。
确定的修改责任人和跟踪责任人。
确定的回归评审时间。
是否都认同评审结论？如果认同评审，则相关人员签字表示同意 评审结论。
结束语:
随着电力行业信息化进程的迅速加快，信息化、网络化的建设已提高到一个全新的水平。而企业的管理水平和掌控水平也最终决定着企业的发展速度和发展方向。因此，对强化需求管理实用化水平，加强和规范信息需求管理工作越来越重要。本文对多维度的需求分类和评审方法给出了定义和分析，在今后需求管控过程中，应当不断完善和规范，从而达到提高需求管控水平的目的。
关键词：功能需求；非功能需求；评审方法
中图分类号：F014.32文献标识码： A 文章编号：
研究背景
现阶段广东电网公司信息系统需求管理总体内容在可管控范围之内，针对具体的需求仍需进行全程管理和跟踪。各个系统需求管理流程和方式各不相同，未制定统一需求管理标准。需求管理实用化程度相对来说较低，人员工作量繁重，重复工作比较多，影响人力资源的使用。对于需求管理信息中心各管理部门未明确管理职责，需统一全面管控。为加强和规范信息需求管理工作、有效落实需求管理全过程闭环机制，公司应针对各系统制定需求管理流程和标准并统一规范。
目前，电网公司正在进行一体化信息系统建设，广东电网也正在进行各种大集中系统的规划和建设，为了能够使大集中系统在建设过程中，避免需求不可控，需求管理不规范的情况，需要设计基于大集中系统的需求管控体系。本文主要对多维度的需求分类以及评审方法进行具体分析说明。
目标和意义
需求分析是一个非常重要的过程，它完成的好坏直接影响后续软件开发的质量。一般情况下，用户并不熟悉计算机的相关知识，而软件开发人员对相关的业务领域也不甚了解，用户与开发人员之间对同一问题理解的差异和习惯用语的不同往往会为需求分析带来很大的困难。因此，在需求分析阶段，能够清晰的描述和组建多维度的需求分类对软件开发至关重要。而需求评审不但是软件开发活动中一个重要的质量控制机制，而且也是一个重要而有效的沟通方式。通过评审可以尽早发现潜在的问题，尽早纠正缺陷，控制纠正成本的滚雪球效应。
需求分类
在一般使用中，需求按照功能性（行为的）和非功能性（其它所有的行为）来分类。
功能需求
功能需求定义了开发人员必须实现的软件功能，它源于用户需求。功能需求是软件需求说明书中最重要的部分之一，它在开发、测试、质量保证、项目管理以及相关项目功能中都起了重要的作用。
需求分析人员理解用户需求，并编写需求规格说明书，对功能的输入、行为、输出进行组合及描述。作为后续设计工作和软件开发工作的最重要依据。
对于功能需求而言，最关键的地方是如何对其进行組织，保证开发人员能够理解在产品中需要实现的软件功能，确保用户利用这些功能来完成任务，满足业务需求。
在需求分析过程中，整理功能需求不是一项一蹴而就的工作，它需要一个长期的过程，而这个过程是一个由粗到细的过程，它体现了人类认识事物的客观规律。在需求分析的初期，我们对需求的认识往往是整体的、宏观的，随着分析工作的逐渐深入，一步步细化。
产品特性，是指一组逻辑上相关的功能需求，它们为用户提供某项功能，使业务目标得以满足。对商业软件而言，特性则是一组能被客户识别，并 帮助他决定是否购买的需求，也就是产品说明书中用着重号标明的部分。客户希望得到的产品特性和用户的任务相关的需求不完全是一回事。一项特性可以包括多个用例，每个用例又要求实现多项功能需求，以便用户能够执行某项任务。
功能需求除了来自于用户需求，还来自于其它几方面需求。
系统需求
用于描述包含多个子系统的产品(即系统)的顶级需求，它是从系统实现的角度描述的需求，有时还需要考虑相关的硬件、环境方面的需求。
业务规则
业务规划本身并非软件需求，因为它们不属于任何特定软件系统的范围。然而，业务规则常常会限制谁能够执行某些特定用例，或者规定系统为符合相关规则必须实现某些特定功能。它包括企业方针、政府条例、工业标准、会计准则和计算方法等。有时，功能中特定的质量属性（通过功能实现）也源于业务规则。所以，对某些功能需求进行追溯时，会发现其来源正是一条特定的业务规则。
质量属性
产品必须具备的属性或品质。系统的质量属性包括可用性、可修改、性能、安全性、可测试行以及易用性等
约束
约束也称为限制条件、补充规约，通常是对解决方案的一些约束说明。
2、非功能需求
非功能需求对产品的功能描述作了补充，它从不同方面描述了产品的各种特性。这些特性包括功能性、可靠性、易用性、效率、维护性以及可移植性。
功能性
功能性指与一组功能及其指定的性质有关的一组属性，这里的功能是指满足明确或者隐含的需求的那些功能。具体包括：
适合性：与规定任务能否提供一组功能，以及这组功能的适合程度有关的软件属性，例如面向任务系统中由子功能构成的功能是否合适，表容量是否合适等等。
准确性：与能否得到正确或者相符的结果或者效果有关的软件属性。
互操作性：与其他指定系统进行交互的能力有关的软件属性。
依从性：使软件遵循有关的标准约定法规及类似规定的软件属性。
安全性：即与防止对程序技术局的非授权的故意或者意外访问的能力有关的软件属性。如用户权限、动态口令、数据库字段加密等。
对于这组非功能需求来说，绝大部分是满足功能需求的情况，他并不需要采用额外的措施，而安全性是一个例外，它会涉及具体的技术性功能需求。
可靠性
可靠性之与在规定的一段时间和条件下软件维持其性能水平的能力有关的一组属性。具体包括：
成熟性：与有软件故障引起失效的频度有关的软件属性。
容错性：与在软件故障或违反指定接口的情况下维持规定的性能水平的能力有关的软件属性。如离线录入支持等。
易恢复性：与在是小发生后重建其性能水平并恢复直接受影响数据的能力，以及为达到此目的所需时间和努力有关的软件属性。如表单数据自动保存等。
这类非功能需求通常是全局的，他除了与系统运行环境、平台选择、代码质量相关之外，还会涉及部分技术性功能需求，他别是容错性、易恢复性的实现都需要一些具体的功能来支持。
易用性
易用性是与一组规定或者潜在的用户为使用其软件所需做的努力和对这样的使用所作的评价有关的一组属性。具体包括：
易理解性：与用户为人质逻辑概念即其应用范围所花的努力有关的软件属性。
易学习性：与用户为学习软件应用所花的努力有关的软件属性。
易操作性：与用户为操作和运行控制所花的努力有关的软件属性。如带首字母筛选功能的下拉列表等。
这类非功能需求是与UI设计、联机帮助系统有着直接关系的，易理解性和易学习性通常和界面导航、联机帮助有关，课归纳为界面友好性；易操作性则会和界面元素设计有关。也就是说这类属性会关联到具体的技术性功能需求。
效率
效率是指与在规定的条件下软件的性能水平与所使用资源量有关的一组属性。具体如下：
时间特性：与软件执行器功能时响应和处理时间及吞吐量有关的软件属性。如数据缓存等。
资源特性：与在软件执行其功能时所使用的资源数量及其使用时间有关的软件属性。如数据压缩等。
这部分实际上就是通常所说的性能需求，他有一大部分是局部性的，在每个用力的描述中应该指出；另外它又会引申出一些相关的技术性功能需求，例如数据缓存等。
维护性
维护性是指与进行指定的修改所需的努力有关的一组属性。具体包括：
易分析性：与为诊断缺陷或者失效原因及为判定待修改的部分所需努力有关的软件属性。如日志记录系统等。
易改变性：与进行修改排除错误或者适应环境变化所需努力有关的软件属性。
稳定性：与修改所造成的未预料结果的风险有关的软件属性。
易测试性：与确认已修改软件所需的努力有关的软件属性。
这部分通常是开发团队最容易投入时间和成本的地方，诸如动态属性支持、UI界面生成、流程引擎等都是为了提高系统的可维护性，因此它显然是会引申出相关的技术性功能需求的。
可移植性
可移植性是指与软件可从某一环境转移到另一环境的能力有关的一组属性。具体包括：
适应性：与软件无需采用有别于为该软件准备的活动和手段就可能适应不同的规定环境有关的软件属性。如全球技术支持等。
易安装性：与在指定的环境下安装软件所需努力有关的软件属性。如在线更新、安装包自动生成等。
遵循性：使软件遵循与可移植性有关的标准或约定的软件属性。
可替换性：与软件在该环境中用来替代指定的其他软件的机会和努力有关的软件属性。
评审方法
在软件开发过程中，需求分析是最开始的工作，需求分析如果做得不够详细或者是偏离用户需求的话，往往会给项目带来灭绝性的灾难。因此如何保证需求分析的正确性，不偏离用户的需求就成了决定软件项目成败的关键。通常需求评审是用来检查需求正确性最有利的手段。
評审的过程不仅是为了发现问题，而且为了便于跟踪及改正，并且对问题进行记录。特别是需要对问题的真实性进行确认，剔除可能是误解、似是而非或不必采纳的建议性问题。
做好评审前的沟通和准备
需求编写人员应将评审所需的资料准备齐全，数据、图表、其他相关资料等，并仔细检查以保证文档质量。
需求文档在评审会议前应提前下发给参与评审会议的人员，并留出时间让参与评审的人员阅读需求文档。
参加评审的人，应该是带着问题而来，而不是来参加培训的。
先沟通好目标，再进行细节的落实。
应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。
分阶段评审保证了需求在形成的过程中不偏离方向，不出现大的错误，降低了需求返工的风险，提高了最终评审的质量。
正式评审与非正式评审相结合
正式评审：是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。
非正式的评审：通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。
两种形式各有利弊，因此在评审时，根据项目复杂程度，紧急程度不同而灵活运用。
评审角色构成
正式评审组的成员一般由用户代表，与项目经理、需求分析员、系统架构师、设计人员、测试人员、QA经理、记录人员以及公司相关领导参加。
需求评审流程
图1 需求评审流程图
评审结论
评审结论包括如下内容：
是否需要修改？这是就成果的整体而言，结论可以是无需、少量、较大或是一个量化的数字。
项目组确定是否接受修改要求？这是针对具体的一条意见或建议。有些问题可能是误会，消除了就不是问题；有些建议性的问题，项目组考虑进度可不接受修改要求。
如不接受修改要求，项目组给出不修改的理由。
如何处理？是否需要进行回归评审？
总体结论：合格或不合格。
确定的修改责任人和跟踪责任人。
确定的回归评审时间。
是否都认同评审结论？如果认同评审，则相关人员签字表示同意 评审结论。
结束语:
随着电力行业信息化进程的迅速加快，信息化、网络化的建设已提高到一个全新的水平。而企业的管理水平和掌控水平也最终决定着企业的发展速度和发展方向。因此，对强化需求管理实用化水平，加强和规范信息需求管理工作越来越重要。本文对多维度的需求分类和评审方法给出了定义和分析，在今后需求管控过程中，应当不断完善和规范，从而达到提高需求管控水平的目的。