论文部分内容阅读
摘 要：文章通过分析软件开发中的用户需求和需求变更管理来探讨软件开发团队应该如何应对这些问题，软件开发团队应该采取哪些对策来解决用户复杂多变的需求。
关键词：软件需求工程；需求分析；需求管理；需求变更管理
1 软件需求分析
软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。包括业务需求、用户需求、系统需求3个不同层次。
在需求获取阶段所得到的需求是杂乱的而不明确的，很多需求既重复又矛盾，而一个合格的需求描述应该具备完整性、可测试性、确定性、无歧义、可跟踪性、正确性、必要性等特性，而需求分析就是把这些杂乱的用户要求和期望转化有效而合格的需求描述的过程。
首先，系统分析师通过对所获取的需求进行分类，创建出不同的业务模型：通过由领域专家（当系统分析师具有足够的领域经验时，可泛化为领域专家）途径得到业务类模型，制作出被领域广泛认可的需求模型；通过与客户/用户沟通得到业务用例模型，获得当前业务的独有特征，再将两个需求集合统一，构成业务模型。
1.1 需求分析的方法
在软件工程的研究中，人们提出了多种需求分析的方法，其中主要有结构化分析法（Structure Analysis，SA）、面向对象分析法（Object-Oriented Analysis，OOA）和面向问题域的方法。另外，还有一些形式化方法，但由于实用性不强，一般只用在学术研究中。
1.1.1 SA方法
SA方法主要关注于功能的分层和分解。这非常符合人们自上而下，逐步分解问题直到可解决的自然思考方式。但通过细分系统模块的功能来描述整个系统做法，很容易混淆需求和设计的界限，使系统分析师感到迷惑，不知道系统需求应该详细到何种程度。并且从用户的角度来看，他们并不想了解系统内部结构和设计，他们所关心的是系统所能提供的服务。SA方法模型的核心是数据字典（Data Dictionary，DD），围绕这个核心分3个层次的模型，分别是：数据模型、功能模型和行为模型（也称状态模型）。
1.1.2 OOA方法
OOA方法主要是运用面向对象的方法，对问题域进行分析和理解。OOA模型独立于具体实现，即不考虑与系统具体实现有关的因素。仅思考“做什么”的问题。OOA使用统一建模语言进行需求的分析，利用用例模型获取需求，进而由分析模型描述系统的基本逻辑结构等。统一建模语言（Unified Modeling Language，UML）通过逻辑视图、进程视图、实现视图、部署视图以及用例视图来体现系统架构。其中又包含了多种不同的图来对所开发系统的某一特定方面进行分析。
1.1.3 PODA方法
面向问题域的分析方法（Problem Oriented Domain Analysis，PODA）是一项很新的技术，目前还处于研究阶段，它主要关注问题域，并关注系统实现的待求行为，用一个文档对解系统的待求行为进行描述。
1.2 结构化分析方法实例
下面以一个嵌入式接口处理软件为例，介绍结构化分析方法的实例。该软件使用串口1与控制器进行交互：要求具备串口升级功能，要求具备由控制器进行启动模式设置完成重启、保存控制器发送的重要配置数据以及将常规指令通过串口2转发至一个外部模块。下面用状态转换图（State Transition Diagram，STD）以及数据流图（Data Flow Diagram，DFD）举例说明结构化分析方法。
根据以上需求可分析出当程序正常启动后进入就绪状态，等待串口语句指令：若接收到升级指令则进入升级状态，升级过程中等待升级数据包，升级完成程序结束等待重启；若接收到启动指令，则进入重启状态；若接收到配置及常规转发指令则完成不同状态处理后重新进入就绪状态。
数据流图按照自顶向下的分解方法，首先绘制一张顶层图，将整个待开发系统表示为一个加工。系统顶层如图1所示，顶层用来描述系统有什么输入输出的数据流，与哪些外部实体直接相关。
完成顶层图建模之后，在此基础上进一步分解，得到图2的1层图示例，1层图将系统细化为3个加工。
继续对1层图中的加工1进行分解，并将所分解的加工命名为1.1，1.2……，可以看到在细化的2层图中引入了数据存储，看到对于配置参数、启动设置数据等需要进行存储操作。就这样在不断细化的过程中完成分析工作。
1.3 面向对象分析方法实例
同样根据上述需求的例子，利用面向对象的分析方法进行分析，通过分析不同参与者所关注的不同需求，得到以下的用例图示例，如图4所示。
在获取用例后，还需要继续深入分析，对用例间的活动关系进行研究，同时对升级用例进行了细化分析，便得到了以下的活動图示例。在后续分析中可使用该方法进行进一步的活动细化。
2 软件需求管理
需求是软件项目成功的核心所在，它是后续软件工作开展的基础和基石。在软件需求工程中，需求管理贯穿于整个过程。
首先，最重要的是系统分析师应充分思考客户的需求，制定计划前要有充分的沟通，若这点没有实现，继续展开下一步制作，只会使得双方的理念偏离越来越大，最终做出来的软件也很有可能不符合用户的商业用途。
编写需求文档，确定需求的范围和标准，加以约束限制，然后对需求进行细化，在具体实施过程中还需进行不断地调整。有时计划赶不上变化，受许多非确定因素影响，若不能及时有效处理这些改变，将会拖延工期，面临很大的风险。
系统设计师对系统自身需求、客户需求都要有深刻认识，要充分了解各个阶段的计划，预测软件开发的进程，软件生产做到有目的性、阶段性、可行性，才能保证项目开发的顺利进行。
在需求管理中，应该认识到整个需求开发过程的各个阶段并不是瀑布式发展的，而是应该采用迭代方式。由这一思想去进行需求管理及控制，保证项目的顺利进行是非常有必要的。需求管理涉及3个主要问题：将需求进行标识、分类以及组织，并为需求建立文档；管理需求的变更，说明不可避免的需要变更是如何被提出、协商、确认的，并且将整个变更过程记录在案；对需求进行跟踪，保持需求和软件产品之间的一致性，及相互关联性。 2.1 需求变更的原因分析
需求变化问题是一直存在的，也是不可避免的，需求不可能一开始就做到百分之百完善，往往都需要在后续阶段不断地改进，对于项目团队而言，必须要正确对待变更，按照既定流程管理变更，尽量降低由于变更带来的成本、进度及质量的负面影响。
需求变更的原因常见有：（1）最初对用户需求缺乏认识，产生了错误，需要改变；（2）用户产业有了变化，软件开发概念也要随之改变；（3）需求了解不够全面，需求要增加；（4）系统的升级换代使软件的运行环境发生改变，软件的兼容性必须满足，安全性也必须提高。
无论是哪种情况所导致的需求变更通常都意味着新需求的增加和原有需求的修改，对于较少发生的减少需求的情况，则比较容易处理。无论对何种变更，都必须采取规范的流程去管理，以保证变更后不会带来新的问题。
2.2 需求变更的管理控制
为保证需求变更不对软件质量产生负面影响，必须规范软件开发过程，开发出标准的管理流程。近些年，软件大量生产，若没有一个规范统一的开发流程模式，软件开发过程中由于需求的变更，增加了生产工期，生产成本提高，扩大了风险，很可能导致项目失败。需求变更动机往往是为了满足用户需要，顺应市场的动态变化，但是为了能使整个工程能够如期完成，必须制定一个合理有效的变更机制，确定一个变化范围，考虑到软件制作的合理性，不能一味地听从用户的体验需求，而不思考项目组能否在不违背完整性约束的条件下开发出软件。对以往的需求变更进行收集、整理、分类，将变更方案的档案记录下来，在下次遇到需求变更时能够快速应对，迅速制作出处理方案。
软件开发做到严格按照流程实施，对需求变更流程路线做到统一规范。首先是对各种需求变更的详细原因进行收集，并写成需求变更请求报告，提交评审小组进行变更评审。在需求评审过程中，对需求变更项目进行审查，将可执行的需求挑选出来，不合理的需求进行排除，还有一部分尚不确定的还需要和用户进行下一阶段的沟通处理，再次通过审核，直到通过评审才能到下一步的流程。而当变更周期完成后，还需要对变更情况进行测试及跟踪。在中途有新的变更时，需要通重新进行这一流程处理。因此看似简单的变更，实施过程中却并不简单。只有严格按照规定流程进行管理，才能得到质量保证与质量的控制。
初步的需求变更完成后，为了加强需求变更后的准确性，技术人员必须对软件进行测试，检查该阶段的性能，保证与其他方面的合理衔接，预测软件的整体运行情况，做到一致和统一，而质量控制部门也必须有质量保证人员执行测试，保证得到高质量的最终产品。
3 结语
一個软件的生产周期中，各个环节都不可以忽视，需求更是软件开发的基础与成功的关键。软件企业应该在软件开发过程中不断地总结问题，提高需求分析及需求管理水平，过程中必须严格按照流程实施。只有在遇到问题积极面对，保证管理者与被管理者的良好关系，才能在确保生产效率的情况下提高软件的质量。
[参考文献]
[1]雷斯泽克，马克扎克.需求分析与系统设计[M].马素霞，王素琴，谢萍，译.北京：机械工业出版社，2009.
[2]张友生.系统分析师教程[M].北京：清华大学出版社，2010.
[3]李超，谢坤武.软件需求分析方法研究进展[J].湖北民族学院学报（自然科学版），2013（2）：204-211.
关键词：软件需求工程；需求分析；需求管理；需求变更管理
1 软件需求分析
软件需求是指用户对新系统在功能、行为、性能、设计约束等方面的期望。包括业务需求、用户需求、系统需求3个不同层次。
在需求获取阶段所得到的需求是杂乱的而不明确的，很多需求既重复又矛盾，而一个合格的需求描述应该具备完整性、可测试性、确定性、无歧义、可跟踪性、正确性、必要性等特性，而需求分析就是把这些杂乱的用户要求和期望转化有效而合格的需求描述的过程。
首先，系统分析师通过对所获取的需求进行分类，创建出不同的业务模型：通过由领域专家（当系统分析师具有足够的领域经验时，可泛化为领域专家）途径得到业务类模型，制作出被领域广泛认可的需求模型；通过与客户/用户沟通得到业务用例模型，获得当前业务的独有特征，再将两个需求集合统一，构成业务模型。
1.1 需求分析的方法
在软件工程的研究中，人们提出了多种需求分析的方法，其中主要有结构化分析法（Structure Analysis，SA）、面向对象分析法（Object-Oriented Analysis，OOA）和面向问题域的方法。另外，还有一些形式化方法，但由于实用性不强，一般只用在学术研究中。
1.1.1 SA方法
SA方法主要关注于功能的分层和分解。这非常符合人们自上而下，逐步分解问题直到可解决的自然思考方式。但通过细分系统模块的功能来描述整个系统做法，很容易混淆需求和设计的界限，使系统分析师感到迷惑，不知道系统需求应该详细到何种程度。并且从用户的角度来看，他们并不想了解系统内部结构和设计，他们所关心的是系统所能提供的服务。SA方法模型的核心是数据字典（Data Dictionary，DD），围绕这个核心分3个层次的模型，分别是：数据模型、功能模型和行为模型（也称状态模型）。
1.1.2 OOA方法
OOA方法主要是运用面向对象的方法，对问题域进行分析和理解。OOA模型独立于具体实现，即不考虑与系统具体实现有关的因素。仅思考“做什么”的问题。OOA使用统一建模语言进行需求的分析，利用用例模型获取需求，进而由分析模型描述系统的基本逻辑结构等。统一建模语言（Unified Modeling Language，UML）通过逻辑视图、进程视图、实现视图、部署视图以及用例视图来体现系统架构。其中又包含了多种不同的图来对所开发系统的某一特定方面进行分析。
1.1.3 PODA方法
面向问题域的分析方法（Problem Oriented Domain Analysis，PODA）是一项很新的技术，目前还处于研究阶段，它主要关注问题域，并关注系统实现的待求行为，用一个文档对解系统的待求行为进行描述。
1.2 结构化分析方法实例
下面以一个嵌入式接口处理软件为例，介绍结构化分析方法的实例。该软件使用串口1与控制器进行交互：要求具备串口升级功能，要求具备由控制器进行启动模式设置完成重启、保存控制器发送的重要配置数据以及将常规指令通过串口2转发至一个外部模块。下面用状态转换图（State Transition Diagram，STD）以及数据流图（Data Flow Diagram，DFD）举例说明结构化分析方法。
根据以上需求可分析出当程序正常启动后进入就绪状态，等待串口语句指令：若接收到升级指令则进入升级状态，升级过程中等待升级数据包，升级完成程序结束等待重启；若接收到启动指令，则进入重启状态；若接收到配置及常规转发指令则完成不同状态处理后重新进入就绪状态。
数据流图按照自顶向下的分解方法，首先绘制一张顶层图，将整个待开发系统表示为一个加工。系统顶层如图1所示，顶层用来描述系统有什么输入输出的数据流，与哪些外部实体直接相关。
完成顶层图建模之后，在此基础上进一步分解，得到图2的1层图示例，1层图将系统细化为3个加工。
继续对1层图中的加工1进行分解，并将所分解的加工命名为1.1，1.2……，可以看到在细化的2层图中引入了数据存储，看到对于配置参数、启动设置数据等需要进行存储操作。就这样在不断细化的过程中完成分析工作。
1.3 面向对象分析方法实例
同样根据上述需求的例子，利用面向对象的分析方法进行分析，通过分析不同参与者所关注的不同需求，得到以下的用例图示例，如图4所示。
在获取用例后，还需要继续深入分析，对用例间的活动关系进行研究，同时对升级用例进行了细化分析，便得到了以下的活動图示例。在后续分析中可使用该方法进行进一步的活动细化。
2 软件需求管理
需求是软件项目成功的核心所在，它是后续软件工作开展的基础和基石。在软件需求工程中，需求管理贯穿于整个过程。
首先，最重要的是系统分析师应充分思考客户的需求，制定计划前要有充分的沟通，若这点没有实现，继续展开下一步制作，只会使得双方的理念偏离越来越大，最终做出来的软件也很有可能不符合用户的商业用途。
编写需求文档，确定需求的范围和标准，加以约束限制，然后对需求进行细化，在具体实施过程中还需进行不断地调整。有时计划赶不上变化，受许多非确定因素影响，若不能及时有效处理这些改变，将会拖延工期，面临很大的风险。
系统设计师对系统自身需求、客户需求都要有深刻认识，要充分了解各个阶段的计划，预测软件开发的进程，软件生产做到有目的性、阶段性、可行性，才能保证项目开发的顺利进行。
在需求管理中，应该认识到整个需求开发过程的各个阶段并不是瀑布式发展的，而是应该采用迭代方式。由这一思想去进行需求管理及控制，保证项目的顺利进行是非常有必要的。需求管理涉及3个主要问题：将需求进行标识、分类以及组织，并为需求建立文档；管理需求的变更，说明不可避免的需要变更是如何被提出、协商、确认的，并且将整个变更过程记录在案；对需求进行跟踪，保持需求和软件产品之间的一致性，及相互关联性。 2.1 需求变更的原因分析
需求变化问题是一直存在的，也是不可避免的，需求不可能一开始就做到百分之百完善，往往都需要在后续阶段不断地改进，对于项目团队而言，必须要正确对待变更，按照既定流程管理变更，尽量降低由于变更带来的成本、进度及质量的负面影响。
需求变更的原因常见有：（1）最初对用户需求缺乏认识，产生了错误，需要改变；（2）用户产业有了变化，软件开发概念也要随之改变；（3）需求了解不够全面，需求要增加；（4）系统的升级换代使软件的运行环境发生改变，软件的兼容性必须满足，安全性也必须提高。
无论是哪种情况所导致的需求变更通常都意味着新需求的增加和原有需求的修改，对于较少发生的减少需求的情况，则比较容易处理。无论对何种变更，都必须采取规范的流程去管理，以保证变更后不会带来新的问题。
2.2 需求变更的管理控制
为保证需求变更不对软件质量产生负面影响，必须规范软件开发过程，开发出标准的管理流程。近些年，软件大量生产，若没有一个规范统一的开发流程模式，软件开发过程中由于需求的变更，增加了生产工期，生产成本提高，扩大了风险，很可能导致项目失败。需求变更动机往往是为了满足用户需要，顺应市场的动态变化，但是为了能使整个工程能够如期完成，必须制定一个合理有效的变更机制，确定一个变化范围，考虑到软件制作的合理性，不能一味地听从用户的体验需求，而不思考项目组能否在不违背完整性约束的条件下开发出软件。对以往的需求变更进行收集、整理、分类，将变更方案的档案记录下来，在下次遇到需求变更时能够快速应对，迅速制作出处理方案。
软件开发做到严格按照流程实施，对需求变更流程路线做到统一规范。首先是对各种需求变更的详细原因进行收集，并写成需求变更请求报告，提交评审小组进行变更评审。在需求评审过程中，对需求变更项目进行审查，将可执行的需求挑选出来，不合理的需求进行排除，还有一部分尚不确定的还需要和用户进行下一阶段的沟通处理，再次通过审核，直到通过评审才能到下一步的流程。而当变更周期完成后，还需要对变更情况进行测试及跟踪。在中途有新的变更时，需要通重新进行这一流程处理。因此看似简单的变更，实施过程中却并不简单。只有严格按照规定流程进行管理，才能得到质量保证与质量的控制。
初步的需求变更完成后，为了加强需求变更后的准确性，技术人员必须对软件进行测试，检查该阶段的性能，保证与其他方面的合理衔接，预测软件的整体运行情况，做到一致和统一，而质量控制部门也必须有质量保证人员执行测试，保证得到高质量的最终产品。
3 结语
一個软件的生产周期中，各个环节都不可以忽视，需求更是软件开发的基础与成功的关键。软件企业应该在软件开发过程中不断地总结问题，提高需求分析及需求管理水平，过程中必须严格按照流程实施。只有在遇到问题积极面对，保证管理者与被管理者的良好关系，才能在确保生产效率的情况下提高软件的质量。
[参考文献]
[1]雷斯泽克，马克扎克.需求分析与系统设计[M].马素霞，王素琴，谢萍，译.北京：机械工业出版社，2009.
[2]张友生.系统分析师教程[M].北京：清华大学出版社，2010.
[3]李超，谢坤武.软件需求分析方法研究进展[J].湖北民族学院学报（自然科学版），2013（2）：204-211.