市场驱动下软件发展过程中需求工程的挑战2.docx
《市场驱动下软件发展过程中需求工程的挑战2.docx》由会员分享，可在线阅读，更多相关《市场驱动下软件发展过程中需求工程的挑战2.docx（26页珍藏版）》请在冰点文库上搜索。
市场驱动下软件发展过程中需求工程的挑战2
市场驱动下软件发展过程中需求工程的挑战
——一种与软件开发人员面对面的访谈学习方式
LenaKarlsson，AsaG.Dahlstedt，BjornRegell，JohanNattochDag，AnnePersson
摘要：
市场驱动软件发展下的需求工程面临着特殊的挑战。
本文给出了一次用于审查这些挑战的试验学习的结果，采用的是一种定性的方法，通过组织来自于八个软件公司的十四个雇员和一组特定软件开发人员进行面对面的访谈。
这种学习方式的目标包括两个方面，一是提高对市场驱动需求工程特定领域的理解，二是通过描述遇到的挑战来为将来的研究提出建议。
许多重大的挑战已被发现，包括消除市场需求和软件开发的沟通鸿沟、选择合适的过程支持、稳定版本计划的不确定性估计、以及管理需求恒定性。
关键字：
市场驱动软件发展；需求工程；定性研究；半结构化访
1引言
本文报告了一份由瑞典软件开发组织给出的关于当前市场驱动需求工程中的实践和挑战的产业定性问题的调查结果。
市场驱动软件能够与嵌入式系统的硬件结合，同时也可以被当成COTS（CommercialOff_The_Shelf）产品出售。
在低效的RE问题能够被合适地解决之前，为了能够更好地理解软件产业所面临的挑战，需要进行更多地研究。
本研究的目的是为了提升对市场驱动需求工程领域的理解，发现和描述当前软件产业存在的RE挑战。
本研究的另外一个主要目的是为本领域未来的研究提出建议，这是非常重要的，因为目前大多数正在进行的研究更多的关注于传统的面向顾客的软件开发方式。
还有，本研究补充了现有RE调查存在的不足，因为目前基本没有研究关注于市场驱动软件开发存在的具体挑战。
这篇论文研究的主要问题是：
市场驱动软件开发公司将会面临怎样的RE挑战？
本研究致力于市场驱动软件开发，在软件开发社区，这项研究与传统的面向顾客的软件开发相比已经得到了越来越多的关注。
这应该归功于COTS或者说封装式软件包市场的出现。
今天，软件是大量商用产品中非常重要的一部分，因此，越来越多的公司涉足到市场驱动软件开发的行列中来。
各种各样的产品，像移动电话、汽车、飞机、玩具、以及游戏，都包含有软件。
市场驱动软件产品销售市场前景广阔，拥有广泛的潜在用户群体，这种情况就需要考虑到用户需求的多样性。
市场驱动产品由于市场竞争的激烈性，常常不断连续推出后续更高版本。
市场驱动RE与传统面向顾客的RE在很多方面有着截然不同的特点，对这一内容的深入讨论将在接下来的相关工作部分中进行。
目前，已经有个别研究涉及到RE问题。
然而，还没有一项研究专心地致力于市场驱动开发。
更进一步说，大多数相关的研究中，研究团队无论是在人员和相关需求方面，还是在时间的持续性方面，通常都非常庞大。
这种定性的研究完成了前面所涉及到的问题并且从中小规模企业发展前景的角度提供了一种市场驱动RE的特征描述。
在本次研究中，来自八个不同公司的十四位相关成员参与了访谈。
经过七次访谈，一份关于国际工作组的简短文档被呈现。
并且，一次包括RE专家的兴趣组会谈通过目前为止面临的挑战的反馈学习的方式被折中地举行。
与每一位受访者进行半结构化的访谈。
对每次访谈录音并用纸质抄写方式存档，以便用定性数据分析工具Atlas.ti进行分析。
本文包括了对所涉及公司的一种描述，关注于公司现实、典型工程和开发过程。
此次研究的结论是一系列有可能提高对市场驱动组织所面临的挑战的认识的重点问题，以及指明未来研究的发展方向。
我们将通过一种定性研究方法来讨论我们的经验。
本文的后续部分将按如下顺序进行组织。
第二部分，介绍相关工作。
研究方法将在第三部分进行描述。
第四部分以一份总结的形式展示学习结果。
第五部分对结果进行讨论并与近期的研究发现相联系。
这一部分中还探讨了有效性面临的威胁以及我们的研究经验。
第六部分对文章进行了总结并对未来的工作提出了一些设想。
2相关工作
此部分介绍了一些近期所做的与市场驱动RE和RE调查相关的工作。
涉及到的参考文献都是些对于我们的研究非常重要的资料，要么关于研究设计，要么关于研究结果。
2.1市场驱动需求工程
虽然市场驱动软件开发和面向顾客的软件开发之间存在一些共通点，但本文重点讨论的仍然他们之间明显存在的不同点。
主要的不同包括项目参与人和进度控制的特点、版本计划以及管理新需求的恒定性。
在市场驱动的工程中，没有非常明确和清晰的用户定位。
只有主要的潜在用户群，这是一群我们认为可能符合产品预期的构想图景中的用户。
对潜在用户和顾客群进行启发式需求引导，是市场驱动RE和面向顾客RE的一个最主要的区别特征。
这主要通过市场、技术支持、用户群和商业公开审阅进行管理。
通常来说，需求分析由开发人员基于商业全局战略目标、相关领域知识和产品前景进行编写。
由于软件开发组织是主要的风险承担者，所以由他来决定下个版本使用哪个需求。
尽管如此，为了保持或提高市场共享，需要挑选出满足绝大多数顾客要求的需求。
这又进一步强调了市场驱动软件开发中市场的重要性。
市场驱动软件开发组织中time_to_market被当做一种遗留属性（标志）。
假如产品没有按时投入市场发行，那将会面临着相对于竞争者放弃市场占有的风险。
因此，版本数据应该被固定，为了避免版本发行延迟，一些低优先级的需求应该从当前版本中剔除。
版本计划仍然是一个主要问题，其目的是在考虑到当前可用资源的前提下，最大限度的发挥顾客可用价值。
然而，仍然存在一系列稳定的由现有用户和顾客或上一版本提出的新需求、改进建议、投诉和错误报告。
因此，需要有效的优先权和投入评估来对版本计划任务提供支持。
更近一步来说，RE过程需要找到一种可以捕捉和保存这一系列稳定需求的方法。
2.2需求工程调查
目前，已经有个别研究涉及到RE问题。
Curtisetal.的经典文章主要关注于大型系统开发工程，既包括传统面向顾客方式，也包括市场驱动方式。
虽然他们的研究不仅仅关注于RE，但还是找出了与RE相关的三个主要问题：
应用领域知识的缺乏、需求的波动性以及沟通和交流的低效性。
Lubarsetal.在几年前发表了他们关于需求模型的研究成果。
和Curtisetal.一样，他们的研究既包括传统面向顾客方式，也包括市场驱动方式。
[25]中提出的问题和[8]的非常一致，包括他们所举的例子，需求描述不明确性、需求遗漏、需求误解、来自开发组织自身的需求描述确定性的缺乏、与顾客交流的缺乏以及经常变化的需求。
接下来，将给出关于RE实践和经验问题的两项研究。
在ElEmam和Madhavji共同发表的论文中，提出的问题更多关注的是工程管理问题，比如进行适当的活动、决定何时停止特定的活动、确保用户充分参与的程度、挑选能力足以胜任的成员充当RE中的关键角色。
在Chatzoglou的研究中，主要论述了一种具有传统面向顾客特点的工程。
提出的主要问题有，缺乏足够的资源来成功完成RE过程，并且在RE过程中没有使用高质量的工具和技术。
和Curtisetal进行的研究不同，Kamstiesetal.的后续研究关注于中小企业所面临的RE挑战，并且既包括传统面向顾客方式，也包括市场驱动方式。
Kamstiesetal.一定程度上支持Curtisetal.和Lubarsetal.的研究，认为不明确的和不完全的需求是一个普遍存在的问题。
另外指出的问题包括，需求文档的复杂性、市场驱动工程需求缺乏文档化以及缺少当新需求实现后会对已经实现的需求造成不可预见的影响的案例。
Hofmann、Lehner和Halletal.近期共同发表的文章中，第一个研究的目的在于，无论是对传统面向顾客工程，还是市场驱动工程，在RE实践过程和最终完成之间建立一个明确的联系。
并且在这篇文章中，还提出了一个问题，那就是需求变化。
他们支持ElEmam和Madhavji的发现，关注于挑选能力足以胜任的成员充当RE中的关键角色这一问题，因为他们发现在定义初始需求时，缺少具有相关领域知识背景的风险承担者的投入与参与。
文献[18]中提出的其他问题还有，市场呈现出的不切实际的需求以及（perceivedadhocREprocess）RE过程中理解进一步来说，他们指出在一项开发工程中大致有15%的投入应该致力于RE。
Halletal.的文章中强调了，大多数的需求问题是来自于开发组织自身的而不是技术方面的。
Halletal.还讨论了公司的成熟度与需求问题发现之间的联系。
最后，有一些RE研究不是关注于广义上所面临的挑战，而是关注于特定类型的挑战，例如由Damian和Zowghi所做的关于由风险承担者地理位置引起的问题。
一般而言，现在进行的RE研究基本上没有一个是纯粹致力于市场驱动软件开发的，而是既包括传统面向顾客开发组织或工程，也包括市场驱动开发组织或工程。
因此，尽管传统面向顾客RE和市场驱动RE之间存有明显的不同，但是无法给出市场驱动软件开发组织所面临的特定RE挑战的综述。
所以，有必要对市场驱动软件开发组织所面临的RE挑战进行深入研究。
3研究方法
本次研究是采用一种定性的研究方法。
定性的研究目的在于研究和理解在他们存在的大环境中的社会和文化现象。
而且，定性研究研究旨在把研究过的现象放在一个整体的框架里面，而且建议对社会和文化现象最好的研究是通过研究人们的行动和口头表达出的思想关于他们活动的社会背景。
在目标是探索感兴趣区，获得一个复杂地区的概观，或是发现多样性而不是相似性时，定性研究方法是很有用的。
当目标是提高对一种不太了解的现象的理解时，使用定性的方法也是更适合的。
这都是归于我们致力于获取深入信息的事实。
在本文呈现出的该研究的目标就是，在市场驱动的软件公司里，获取深度的对需求工程（RE）性质的理解，特别是着眼于探索软件开发公司在该区域的挑战。
该目标也为明确阐述对未来研究的假定提供了基础。
由于本研究的这种探索性，定性的方法被认为是合适的。
研究主要是基于半结构化的会谈，其中包括会见者和被会见者之间高度的讨论，并补充了一个中心组会。
这种方法使研究者对某些东西获得了深入的理解，例如公司使用的概念/术语。
这证明了持续的帮助数据分析。
例如，诸如需求、进程和方法等概念在公司中有不同的含义。
两者择一的方法可以用于调查问卷中。
这种方法的缺点就是在那时候研究者的假定控制了提出的问题和使用的术语。
因此，研究中探索性的元素就很难取得。
此外，调查问卷不能提供机会来讨论问题和概念的意义，以及探索在面对面交谈中可能出现的新的看法。
定量的方法有时自称是比定性方法要好，论据是相对于定性方法以内在的主观说明为基础，定量方法能提供客观的度量而且能复制研究。
然而，我们不会考虑通过争论哪种方法会更好来增益于科学。
相反，我们需要对长期研究的更全面的考虑（见图1）。
长期研究的阶段需要对假设/理论的探索和理由/证明/确认。
探索阶段接下来是求证然后是发现新理论或理论的基础，这需要进一步的求证等。
在本文中报告的研究中，我们已经在以市场为驱动的软件开发公司中发现了许多的RE方面的挑战。
这些挑战可以视为假定或是新假定、研究和实验建立和执行的基础。
本研究包括三个步骤，描述如下。
每个步骤分成三个阶段：
规划，数据采集和分析（见图2）。
3.1步骤1–会谈研究（第一部分）
3.1.1．规划
本研究第一部分包括“自由讨论”和计划会议来识别不同的感兴趣区并规划该研究。
我们使用了一个最大变量取样和便利性取样的结合，由于我们在我们产业合作网络中选取尽可能有不同特点的公司。
我们着眼于各种各样的公司，考虑到规模，进程的类型，应用领域和产品类型。
我们以五个公司开始，会见了7个人。
参与进来的被接见者有不同的角色，目的就是收集关于RE性质的不同的观点和看法。
会谈的文件的设计考虑了不同的感兴趣区并借鉴了其他RE调查的灵感。
为了测试会谈的文件，进行了两次试验性的会谈。
阐明了一些问题，在会谈进行之前，会谈的文件的结构也改善了。
会谈文件的总结在附录表A中可见。
3.1.2．数据采集
本次研究使用了一个半结构化的会谈策略。
所有的会谈包括一个接接见者和三个接见者，其中一个负责整个会谈进程。
另外两个做大量的会谈记录以便能收集尽可能多的信息。
所有的会谈时间从90到150分钟不等，都会记录下来。
为了促进和提高分析处理，所有的会谈都做了副本。
副本大小在7到23页之间。
3.1.3．分析
内容分析包括标记和讨论副本中感兴趣的章节。
接见者检查了不同视角的副本并搜索了明确陈述的或是隐藏的RE挑战。
另一个没有参加会谈的研究者也要分析副本力求其有效性。
第一步的结果在文献[24]中讨论到了。
3.2．步骤2-中心组会
3.2.1．规划
中心组会的目的是获得来自RE专家的对迄今发现的11个RE挑战进行的反馈也是为了发现更多的RE挑战。
因此，我们选择了在步骤一中受访的两名参与者，以及三个没有参加任何会谈的三名新的参与者。
3.2.2．数据采集
会议开始于一个“自由讨论”的短会，其中5名工业RE专家依据他们各自的经验在便签纸写下一些挑战。
短会是由到场的5名研究者中的一名维护的。
然后，工业专家把他们写的便签纸的内容对应到第一部中发现的挑战中。
一些便签纸不能和一个挑战对应，结果就行测很规划出了三种新的挑战。
所有14个挑战都基于一个简单的计划进行优化；每个参与者都有10张票来投给那些他们认为最重要的挑战。
3.2.3．分析
5个研究者进行大量的记录，会后将会对记录进行讨论和编排。
在本阶段，没有特殊的由记录得出的分析。
相反，记录被用作步骤3分析中的输入，即在会谈研究的第二部分。
3.3．步骤3-会谈研究（第二部分）
3.3.1．规划
我们继续采用本研究第一步中提出的取样策略，而且访问了来自5个软件公司的7个人。
新公司有大的和小的机构。
非常大的和非常小的项目出现在新公司中，为了扩大范围，更多的注意力也集中到嵌入系统的开发者身上。
会谈文件也做出调整。
一些问题变得更具体，其他的则给定了更加开放式的结构。
3.3.2．数据采集
继续采用半结构化的会谈方法。
会谈长度从60分钟到120分钟。
一个会谈由于缺少时间同时会见了两个受访者。
所有的会谈都是由三个采访者中的一个主持的，并且都录在磁带里了。
和步骤一一样都做了会谈记录，而且每个会议在分析之前都经过抄写。
3.3.3．所有数据的最终分析
由于我们寻找一种关于完全数据集的综合的观点，因此本研究第一部分的数据和中心组会以及会谈研究的第二部分的数据结合起来进行分析。
分析由定性数据分析工具支持。
由于数据量很大（抄写文本就超过160页），为了维持复杂的整体，工具支持以及促进工作在不同地理位置的研究员之间的合作是很必要的。
在最终的分析中，我们使用了在第一次会谈中出现的11个挑战以及在中心组会发现的3个额外的作为预定义的类别/准则。
同时，通过讨论和处理数据，随着我们对数据的理解的增加，一个新的类别出现了。
因此，15的类别建立起来了（见表1）。
每个类都用引用和例子进行描述，目的是建立一个对每个类一般的理解。
在每个类里面我们发现了更多详细的挑战，并进行了进一步的分析。
参考了扎根理论，贯穿本研究三个步骤的过程达到了所描述的理论饱和状态。
从每一步产生的新类别的数量变得越来越小，从11到1。
除了一个多余的类，第三步主要提供了更多细节并确定了之前的发现。
在表1中有说明。
会谈副本分给两个研究员去编码。
副本经过了分析而且有意思的引用用15个类别中的1个或多个标记上了。
然后，研究员改变了会谈，由于编码是以一致的方式进行，从而使会谈变得有效。
那时，增加更多的类别也是可能的。
每个研究员在文件中保存了一份材料其中包含由该研究员编的代码。
当编码结束时，两份单独的资料并入分析文件中的一个。
对于分析报告，对于每个类的所有相关的副本引用都进行编译和打印，将数据编制成只读的格式。
研究结果可从第四节看到。
为了进一步保证编程过程的质量，没有参加会谈的第三方研究员将副本和本文给出的结果进行比较。
在结果中的引用可以追溯到副本中他们的源来检查翻译并确保解释是相似的。
由于可追溯的问题，主要由瑞典人的翻译导致的，两个引用没有在大量的副本材料中复原，最后从结果中移除了。
一个引用变成了一个描述性的解释，因为没有丢失所提到的本质的翻译是很困难的。
在6个引用中，单独的字都被清除或改变以获得更好的语言结构。
4结果
这部分展示在分析采访和讨论组会议过程中，发现的挑战。
以下12子部分将展示和讨论一种或多种挑战，和Table1中的一致。
公司和受访者的特征在附录中TableB中给出。
这些挑战使用从副本和解释摘录的方式详尽的说明和解释。
4.1对基本需求的简单技术
Rational统一过程（RUP）被许多受访者提到，随着发展过程被应用。
例如，F公司的员工使用RUP和Rational工具很多年了，他们总体上满足他们的表现。
但是，一些问题也被提出来，RUP在需求工程师和设计者移交过程中缺少支持，另一个问题是当公司想使用特征驱动的方法，而RUP是使用事件驱动方法，这在特征和使用事件之间的描述增加了一些工作量。
在E公司，RUP和Rational工具都被使用，但是员工很难接受的这个过程。
管理总监评论说：
“它太复杂了”。
在B公司，RUP正在考虑中，但是在整个团队中，很难找到时间和引进RUP。
项目经理评论：
“我们不必要使用RUP和那些工具。
”这个项目经理需要一个RE（需求工程）工具为了支持项目的需求工程，例如DOORS。
因此，对工具支持的需求好像随着在项目中角色的不同而不用，而且在小的项目组中这些工具更适合他们使用，因为他们很难找到处理方法。
在讨论组会议中，讨论缺少支持一个灵活处理方法的工具，还有一个问题就是很难结合不用的工具（例如，RE工具和测试工具）。
一些公司在详细规格说明书中使用统一建模语言，关于UML不同的被访者的意见不同。
在C公司，把UML认为是易于顾客理解的工具，但是E公司却说：
“你不可能把模型给一个没有达到硕士程度的人看”，因此，这不是一个很好的和顾客交流的工具，对于UML不同的观点可能是由于顾客特性的不同。
由公司C开发的软件是为开发者和产品经理准备的，同时公司E是为经理和业务流程开发者准备的，H公司尝试了一种用例方法，但是由于他们察觉到作为一个客户交流的反馈工具，这个方法存在缺陷，所以将放弃了该方法。
另一方面，他们积累了一些值得肯定的得到顾客反馈原型的经验。
他们说他们需要技术和方法，能很容易理解顾客的反馈。
4.2开发者与市场人员的交流鸿沟
在讨论组会议中，大部分的参与者认为在组织的不同部分缺少合作，特别是市场和开发。
一个参与者说，“如果这两个部门交流，我们甚至不必详述需求，如果每个人都相同的目标和视野，那么每个人都朝着正确的方向工作”。
在B公司中，项目经理建议解决在市场和开发者之间缺少交流和沟通的一个方法是对市场的员工学习UML，它能对于需求的交流担当起一种通用语言。
在公司A，在市场和开发之间的交流鸿沟也很明显，市场部门的制定需求的视角是对于将来的功能性写下想法。
但是开发者希望清晰和详细的需求，这个需求能被用于设计。
没有人对需求规格说明书负责，并且分析需求。
在公司F，这个问题被一个系统管理组管理，这个管理组在市场和开发者扮演一个“冲裁人”，同时，把从市场的需求重新阐述，成为对开发者的可设计的需求。
在F公司，通过系统管理人是一个很好的解决方法。
作为系统管理部门，产品管理不需要有详细的知识。
另一个沟通问题关于在顾客会议之前，倘若营业部有足够多的信息。
在公司B，存在这样的实例就是在确认它的可行性之前，销售人员答应顾客产品功能性。
在讨论组会议中，作为挑战被提了出来，建议销售部门和需求工程师沟通来解决这个问题。
另一个在部门之间关于什么是好的需求有不同意见体现了有交流鸿沟。
在公司B，产品经理认为一个好的需求是低投入高回报的产品，它可能买的很好。
在公司C的管理主管表达了一个相似的观点，但是，通过在同一个组织的开发者，好的需求是独立的、可测试的，清晰的并且没有冲突，这好像依赖于组织中不同的角色对好的需求的概念不同。
4.3书写易懂的需求
大部分公司使用自然语言（NL）来记录他们的需求，这是对于大部分被访者是足够的，因为这是顾客的语言并且顾客需要理解需求，但是，在H公司的一个被访者说不用的股东使用不同的语言，或者他们使用同一个单词但是不同的意思，这是自然语言有问题。
生产出一个好的构思的需求是一个难题，因为很多的被访者发现他们很难理解需求，在C公司的开发部主管认为在实施日常的工作中这是一个主要的挑战，但是在同一公司的管理总监不认为这是一个主要问题，在一个组织中，不用的观点似乎关系到他在组织中的角色，可能市场部员工不需要对需求理解太深，因此他们能处理一些不是很好的构思的需求。
但是，开发者可能需要理解更多的管理执行。
很多被访者花很大力气去通过组讨论会来增加需求的清晰和易懂，公司C的开发部主管说：
不能写出很完全的、清晰的需求，你一直需要和其他人讨论。
”
4.4新需求的横流管理
以市场驱动的产品的开发者需要处理一个新产品需求的定量流动。
这被认为对收集来源于像顾客、用户、开发者和辅助人员的全部新的有潜力的价值的想法很重要，但是，这需要有效的方法来管理他们，很多公司使用储藏室或者工具来存储新的需求，同时有价值的需求在下一个产品发布会上执行。
在公司B、C和G，相同的储藏室被用于存放需求问题报告，因为他们是相同的资源，即使一个储藏室保证没有好的想法丢失，但是它也有很多挑战。
首先，公司A、C和D允许他们的顾客和其他的股东进入需求和想法。
但是，这个需要各方面努力为了提高陈述的理解和识别出大部分需求中的完全一样的需求。
第二，公司A，有一个成熟的产品，在需求数据库中有很多严重负载的问题，因为很多需求比起他们管理的，都是额外的，这导致了在下一个发布的时候，很难确定的优先发展权，因为有成千上万的需求要被考虑，这个问题暂时可以建立一个列表包括被下次发布考虑的最重要的需求来解决，但是，这有一个明显的问题就是有一些舍弃的需求可能更重要。
第三，在D公司的项目经理强调从股东的所有建议反馈的重要性，否则他们可能感觉被忽略，“如果他们知道他们的建议没有送到任何地方，他们可能会停止建议，”因此，顾客知道所有的建议被考虑是非常的重要，但是，从大部分顾客的新需求的恒定流动得到反馈需要大量的努力。
4.5需求的挥发性
需求改变有很多不同的原因，例如，当市场波动，问题在编写代码或者检查的时候发现，还有资源限制条件改变了。
一些被访者害怕易变，然而其他人希望如此。
例如，在公司B的项目经理说：
“在产品是稳定的之前需要花费时间，这个目标是你想达到的。
”另一方面，在公司D，作为软件发展的一个现实，易变是可以接受的。
这个项目经理说：
“顾客在任何时候当他们看到产品时会改变他们的想法。
”因此，他们使用一种敏捷开发方法。
他也说到：
“代码是廉价到可以扔掉，它几乎是免费的。
”因此，这很可能开发一个有瑕疵的软件并且展示给顾客，得到反馈。
这种方法在公司C也用到，这种方法的功能大多数情况达到60%到90%，所以能更早的得到反馈，而不需要花费100%计划好的资源。
一个开发者说：
“不值得完成100%的需求，因为需求的改变马上到来，所以我们更早的完成它等待意见。
”在稳定性和易变性的权衡在讨论组会议上被讨论，其中的一个参与者说：
“环境变化了，但是我们想在项目中，按着详细设计说明书开发并且争取它的稳定性。
”另一个参与者建议需求模型应该很容易改变。
4.6需求的可描述性和相互依赖性
涉及的所有的参与者应该学习各个需求之间存在的关系和相互依赖关系，但是，关于他们关于这个重要性的认识和对研究工作影响在不同公司之间是不用的。
影响因素似乎是如何详细说明和定义RE过程是什么，但是更重要的是产品的大小和复杂度。
在六个公司中，各个需求中的关系和依赖程度通常用于相关的需求捆绑在一起共同执行。
捆绑式为了在执行过程中增加效率，因为需求与系统同一部分相关联或者应该由同一个开发者编写。
升级会员 