雷竞技网页版研究和评论——国际期刊雷竞技苹果下载

全球研究计算机科学杂志》上

菜单

石头:2229 - 371 x

所有提交的电磁系统将被重定向到在线手稿提交系统。作者请直接提交文章在线手稿提交系统各自的杂志。

再保险的有用性在S / W发展实践

Dhirendra Pandey1 *,Ugrasen Suman2Ashwani Kumar Ramani2
  1. 部门,比比安贝德卡大学、印度勒克瑙(U.P.) -226025
  2. 计算机科学与信息技术学院的戴维Ahilya大学印多尔(MP)——印度
通讯作者:Dhirendra Pandey,电子邮件:prof.dhiren@gmail.com, Ugrasen123@yahoo.co。,ramaniak@yahoo.co.in
相关文章Pubmed,谷歌学者

访问更多的相关文章全球研究计算机科学杂志》上

全球研究计算机科学杂志》上

文摘

要求工程(RE)的研究报道,不完整的需求规范,不受控制的变化要求,不安全的和过时的需求引出,缺少用户责任人是软件故障的主要原因。提出了研究介绍了各种需求工程问题,可以有助于制定有效,安全,更新,和质量要求的工程软件开发的过程。系统回顾需求工程实践以及我们发表的研究工作包括流程模型,信息需求工程(愤怒),安全性要求工程(行为)和需求建模是强调,以及测量分析,提出再保险流程模型也是研究的这篇文章中描述。

介绍
要求工程(RE)是一种重要的软件开发以及具有挑战性的实践。提供用户需求的过程,进一步可以用来实现在软件开发中。系统执行再保险可以对系统分析师发现有用信息,实现项目目标。[1,2]。我们发现,最常见的问题与软件开发相关的相关要求。分析报告说,不完美的要求,改变需求和规范以及缺乏用户兴趣是引用的因素,导致项目挑战[39]。因此,一个正确的、一致的和完整的方式收集、理解,指定并验证用户需求的软件开发是必要的。
此外,再保险是一个系统化的方法来试探,组织和记录系统的要求。这是一个过程,建立并维护客户和项目团队之间的关系的系统不断变化的需求。再保险是软件开发过程的关键步骤,因为错误在这个阶段不可避免的导致了后来软件开发过程中的问题。在观察,我们发现,检测和修复错误在维护阶段可以更昂贵比阶段。因此,再保险公司的成功是一个关键的过程产生高质量的软件产品。许多研究人员感兴趣的分析的实践,因为这一地区有很大的关注和未来的范围。
本文探讨了各种需求工程等方面,要求引出,要求规范,要求验证和确认。同时,分析所需的要求设计、开发、测试、实施和维护系统或软件产品。开发高质量的软件产品的需求是一个重要的里程碑。在以下的研究文章中,提出的最先进的和研究目标研究提出了在随后章节2和3。要求工程问题,即。,information RE, security, RE, etc. are described in Section 4 and their subsequent sections. Finally Section 5 presented the concluding remarks. A bibliography in the latest research on RE is also included at the end of the article.

最先进的
再保险的目的是确保软件开发团队生产软件或系统,满足用户需求。同时,再保险的主要目标就是捕获需求从各种利益相关者和实施软件开发活动[39]。因此,再保险公司在软件开发过程的影响非常巨大的研究范围。再保险过程主要集中在两个重要方面,即;需求开发和需求管理。需求开发包括启发式、分析、规格、验证和确认活动。在需求开发中,确定预期的用户类的产品,从用户可以进行分析和接收信息。
此外,需求管理是一个关键的活动,包括等阶段,跨产品管理需求随着时间的推移和家庭[11]。这种观点的再保险软件开发是一项非常重要的研究领域具有良好的研究工作和有一个伟大的软件开发的范围有可靠性和满意度。软件开发的成功取决于适合用户的需求和商业环境(3、4)。许多研究人员已经提出了他们的研究工作实践。信息系统(是)的设计者和程序员经常开始设计和编程现任系统没有正确理解用户或利益相关者的需求。此外,我们已经观察到未来系统是有效的,它必须是设计者和程序员的技术视图之间的平衡以及社会对用户和客户[39]。从文献调查,我们发现,精心确定并引起软件需求是项目成功的关键问题[6]。同时,校正后的系统错误的成本交付完整的系统的成本高于纠正一个类似的错误在需求分析阶段[7]。由于在开发过程中需求经常变化,重要的是管理不断变化的需求[8]。存在各种软件措施需求管理活动也被发现在文献调查。 A set of requirement indicators have been observed which are compatible with the measurement practices of the Capability Maturity Model (CMM) for software [9]. Some research works have made state of the practice surveys that are used for developing large information system with the help of RE [29]. Also, various researchers have given a detailed analysis for managing information system for industries. They have also made survey and clarified the fundamental problems in RE practices [10, 11].
系统分析人员重新过程中起着重要的作用。已经有相关的各种研究问题和未来的研究方向等,技术的提高,再保险过程的建模、需求复用、全球化等曾被观察到在文献调查(12、13)。另一方面,是实践的重要性分类软件包也被发现在文献[14]。实证证据存在的文献也表明,组织问题重要的过程(15、16)。一些研究人员介绍了反需求[17]。这是一个恶意用户的需求,颠覆了现有的需求。它可以为每一个软件组织是危险的。各种研究发现已经认识到的重要性,将客户的要求融入到创新过程[18]。
在过去的几十年里,许多研究人员调查和综合安全分析和实践。安全是最重要的一个系统产生准确、安全要求和高质量的软件产品(19、20)。一些研究者也感兴趣提高再保险实践和定义过程,因为他们的信心,你可以开发一个成功的系统的关键(21、22)。然而,实现整个组织工作产品和说服用户应用软件开发实践过程是相当大的挑战[23日,24日,25日]。在过去的一些年重新给了一个重要的关注为设计高质量的软件产品开发人员和研究人员。组织化的再保险实践的成功取决于人类,社会,文化,全球个人、组织、技术和经济问题(26日27日28)。

研究目标
为了进行再保险,系统要求必须正确识别,分析和回顾了在软件开发过程的早期。重新关注发现、分析、记录和管理系统需求在软件开发过程的早期阶段(29、30、31)。重新研究实践表明,再保险过程严重影响成功的软件开发过程。在本研究的文章,以下研究目标提出了分析各种再保险问题在软件开发中,因此,可以观察到再保险的有效性。
和实践。分析了再保险问题:系统的成功取决于利益相关者的过程和健身需求。提出研究的目的是调查和分析的有效性在软件的开发过程。它可以由包括需求管理和需求开发技术分析。同时,采访和社会组织参与的研究重新研究的困难是另一个重要的目标。SRS文档中的安全需求的影响也纳入研究。这项研究表明,再保险的质量实践成功的软件开发过程的影响
b。设计一个再保险流程模型:被公认是最关键和复杂的过程在软件系统的开发。它有助于描述一个多学科需求工程过程的作用以及社会互动的模式。此外,一个有效的需求工程过程模型可以帮助需求引出,规范,验证和确认和需求管理。这项研究的目的是介绍再保险和需求管理的过程模型。再保险的适应过程在软件开发中提供了一个良好的影响软件产品的生产质量。再保险模型也可以用于大型软件开发过程中,需求可以随时间变化的地方。
c。将安全需求问题RE:这项研究的目的是将安全需求问题的过程。安全要求可以用于一个组织设计准确和安全的软件产品。安全性要求也给予重大关注近年来开发安全软件产品。因此,安全的方法是必要的,以避免可能的威胁,比如,反要求,泄漏、窃听等在建立安全需求之间的关系和规范的软件性能
在RE: d。有用的信息分析和提取有用信息根据所需的业务和技术需求总是决策。研究的目的是提供一个框架,信息RE(愤怒),收集来自各种来源的信息,比如市场调查,利益相关者和竞争对手的组织。收集到的信息将被处理和最终软件开发满足市场需求。愤怒的方法是定义信息的客观需求,可以帮助软件开发人员以有效的方式收集信息从不同的涉众和用户。
e。重新测量分析过程:提出重新设计流程模型测量分析软件产品质量的另一个重要的目标提出了研究。提出了基于系统动力学模型的测量以及性能分析测量性能的各种现有的和拟议过程,在质量、成本和进度的依从性。因此,提出了过程模型与现有模型相比。最后,我们发现,无论是线性模型还是纯粹的迭代模型能够执行的每一个活动过程。同时,发现的过程模型可以从线性的组合是有益的和迭代结构
f。建模需求框架:大部分的需求文档往往是模糊的,因为这些都写在不那么正式的和不精确的自然语言。一般来说,可以看出这些需求通常聚集在文本格式,可能是模糊的,不清楚,有时它可能被覆盖了。没有建模的需求文档,需求是很难理解的。这项研究的目的是提出需求建模框架提供清晰的视图的用户和利益相关者的要求,从而模糊可以最小化。模型加强要求工程师理解和引出模糊的和隐含的需求。

要求工程实践
再保险是软件开发的一个重要阶段,它的成功取决于各种社会和组织问题。再保险的各种重要技术问题的适当使用工具和技术(即。,graphical editing and traceability, behavioral modeling and databases, and word processing, etc.), effectiveness of various RE dimensions (i.e., requirement elicitation, requirement specification, and requirement verification and management, etc.), and the implementation of RE practices [35]. The proper employment of aforesaid RE issues in software development results in quality software products. Another challenging issue in RE is to conduct interview for requirement gathering in a systematic manner to avoid software project failures. The improper capturing system requirement is the major factor in failure of 90% of large software projects and poor requirement management can be attributed to 71% of software projects failure [36]. The research output indicates that, failed or an abandoned system by aforesaid reasons causes major loss in software industries.
面试相关信息收集等各种在线数据库,学术研究图书馆(ACL),即,ProQuest, Australian Public Affairs (APA), Full Text (Informit), Business Source Premier (BSP), Communication & Mass Media Complete (C&MAC), i.e., EBSCO, Emerald Management Xtra, i.e., Emerald, Expanded Academic ASAP (Gale), Factiva, ACM library and the IEEE Library. In addition, some of the information is also retrieved from Google Scholar and Google Search. The key references from various online databases and search engines were explored to find out requirement gathering information through interview. At last, we have found that many authors imply to be talking about requirement gathering, but quickly gloss over these issues and then perform research on one of the requirement analysis techniques.
面试在这个研究中,我们使用模型和认知科学有效采访收集的清晰和完整的需求从各种利益相关者[46]。面试的模型可以帮助利益相关者之间进行有效的面对面的讨论。采访时模型来说明有效需求收集过程,如图1所示。模型可以用于传导有效的面对面的分析师和用户之间的交互,以引出要求。这个模型有四个部门,即。,conspicuous requirement, user knowledge, analyst knowledge and mutual understanding between user and system analysts. The conspicuous requirement can be shared either user or analysts, whereas, the user knowledge and analyst knowledge are required to exchange between these stakeholders for imperative requirement gathering. Also, the mutual understanding between stakeholders can overcome the conflicts that arise in interview process. The segments of the models are described in the subsequent paragraphs. Division A represents the knowledge, which is common to both analyst and user. Repeated interviews would hope to increase the size of this quadrant.
部门C代表了分析师的知识但是最终用户没有。它包括知识的分析技能和获得的知识教育和培训。利用这些知识,分析师将能够提供产品知识。的知识没有用户,但分析师表示在分裂b,它包括用户的独特商业模式的理解业务。分析师试图从用户学到这些知识。D代表新知识的交互创建用户和分析师。
图像
Figure.1。采访模型显示了元素(用户)和(分析师)
我们认为,分析员可以提问收集更多的来自用户的需求和用户回答问题从而要求可以定稿。认知面试方法的主要目的是评估响应错误的起源在通过一个跨学科的努力使用调查问卷调查方法学家和心理学家。
它主要关注问卷管理过程,而不是整个调查受访者使用回答调查问题。进行认知的采访中,招募志愿者,并采访了在实验室环境中或在其他一些私人的位置发现隐藏的需求。认知采访处理人与人之间的沟通,阻碍了人类认知的局限性。尤其是,这样的交流出现问题时需要进行的一些特定的语言。沟通问题在这个过程中可分为人类的局限性信息处理器,认知需求的复杂性,和在用户遇到的障碍和分析师交互。研究报道,互动障碍特征的认知采访中也可以通过公司内部政策或外部客户的特点。有一些研究工作进行语言困难,这是由于不同的软件开发术语。
最富有成效的结果也可以由个人认知理论应用到改善利益相关者之间的对话表演,增加需求收集的能力。需求收集的一个重要的问题是无效的客户和开发人员之间的关系,结果可怜的需求收集过程,使软件项目失败。一些研究人员发现,绝对是缺乏专家对他们的关注引起的信息或知识。一个有效的行为之间的关系可以发现利益相关者和高质量的学习成果。教学方法是为了鼓励成功学习行为。一个强大的关系可以从利益相关者的经验,找到学习的本质,学习成果的价值。基于我们的研究报告的结果,我们发现,改进的理解需求收集对话可以通过认知面试方法。最后,研究成果是,面试是最有效的方式获取需求,如果它机智地执行。
保留59

回答调查问题。进行认知的采访中,招募志愿者,并采访了在实验室环境中或在其他一些私人的位置发现隐藏的需求。认知采访处理人与人之间的沟通,阻碍了人类认知的局限性。尤其是,这样的交流出现问题时需要进行的一些特定的语言。沟通问题在这个过程中可分为人类的局限性信息处理器,认知需求的复杂性,和在用户遇到的障碍和分析师交互。研究报道,互动障碍特征的认知采访中也可以通过公司内部政策或外部客户的特点。有一些研究工作进行语言困难,这是由于不同的软件开发术语。最富有成效的结果也可以由个人认知理论应用到改善利益相关者之间的对话表演,增加需求收集的能力。需求收集的一个重要的问题是无效的客户和开发人员之间的关系,结果可怜的需求收集过程,使软件项目失败。一些研究人员发现,绝对是缺乏专家对他们的关注引起的信息或知识。 An effective relationship can be discovered between behaviors of the stakeholders and high quantity learning outcomes. Teaching approaches were designed to encourage successful learning behaviors. A strong relationship can be found from stakeholder’s experiences, the nature of learning, and the value of learning outcomes. Based on the findings of our research reported, we have found that the improved understanding of requirement gathering conversations can be obtained by cognitive interview approach. Finally, the research efforts have originated that interviews are the most efficient way of acquiring requirement, if it is performed resourcefully.

社会(即之间的有效参与。、用户、客户、等等),和组织(即。,developers, analysts, etc.) elements is another important issue in RE, which can affect the entire requirement gathering process. One of the challenges is that each community interprets things in the light of their own background assumptions. This is especially problematic with non-interactive participation, where there is less opportunity to verify that the reader has interpreted requirement as it was intended. The requirement engineering phase is characterized by the strength and significance of participation activities. During this phase, various stakeholders must be able to communicate their requirement to the analysts and vice versa for their validation. The presented study describes a field investigation into the problems of participation among disparate communities involved in the requirement elicitation and specification activities [37]. In this research, a combination of learning, data gathering and analysis techniques were applied to investigate the participation problems [37]. The literature survey and empirical study have been used for the research on participation difficulty. The cross sections of social science and Computer Supported Co-operative Work (CSCW) literatures were also surveyed to analyze the empirical results and reasoning about possible causes and consequences of participation difficulties.
在参与研究工作的困难是在两个阶段进行。第一个由非正式的利益相关者之间的相互作用和建立一些知识实践和观察方法的开发人员和他们的客户。这些交互或面试主要集中在利益相关者之间的参与渠道参与软件开发项目,以及无效的问题,可以归因于那些参与渠道。其他管理和技术等问题,地点和安排面试等也进行了讨论。大多数这些访谈记录进行进一步分析和参考。第二阶段的工作是基于两个调查问卷;一个利益相关者,另一个用于软件开发人员。这些问卷设计获得定量评价的需求收集期间参与活动的各个方面。调查问卷被送到一些印度软件公司和他们的反应代表组织的公司目标。
这项研究的结果,讨论了术语关系的三个主要参与障碍,即。,effectiveness of the existing participation channels, restrictions on expressiveness imposed by management as well as social and organizational barriers. There are two standard approaches to resolve aforesaid problems. The first approach emphasizes on development of better notations and effective use of electronic repositories. The second emphasizes on the importance of interaction between development team and other stakeholders that has given rise to practices such as, end-user participation and ethnographic techniques. Each of these approaches has its own set of limitation, and neither directly addresses the question of facilitating appropriate and effective participation over restricted channels. The study indicates that the practitioners should adapt a compromised form of the two approaches for aforesaid participation barriers such as, by enriching notations with natural language descriptions and utilizing the personal contact of face-to-face discussions [37].
此外,安全需求的影响在软件需求说明书(SRS)文件也确认和讨论。我们发现,安全部分通常是没有或部分包含在SRS文档。因此,安全要求可以在非功能性需求的一个重要组成部分SRS文档。例如,需求,关心的可能损失,损坏,或伤害,可以包括在安全要求规范。这一节还指定了对风险保障措施或采取的行动,以及所有必要的行动,可以用来防止各种风险。安全或隐私等问题,用户身份认证需求和物理安全需求也应该被包括在SRS文档。此外,它是指一些外部政策或法规包含安全问题,会影响软件设计或编码[38]。
简而言之,提出研究的一些重要问题讨论等,适当使用的工具和技术,访谈,和参与客户和开发人员之间的困难。的安全性要求SRS文档中有很大的影响,也在这一节中。

再保险过程模型:
系统重新过程可以帮助系统分析人员改进软件开发过程。存在各种有效的流程模型,即。,Kotonya, Maculay, and Shams-Ul-Arif RE process model [19, 45]. These existing models are limited to cover only few RE dimensions such as, requirement elicitation and requirement specification. Also, these process models are unable to incorporate their phases with software development process in the right manner. It is generally accepted that the requirement can change over the time and during software development process, which causes the unexpected results. Hence, controlling and managing the continuously changing requirement is become more necessary for quality software development. Therefore, we have presented a different RE process model for proper software development and requirement management which is shown in Figure 2.
该模型主要有四个阶段,即;需求引出和开发,文档要求,确认和验证的要求,和需求管理和规划。需求引出和开发阶段包括需求分析和分配和流动的要求。需求包括识别的需求文档,软件和系统需求规范。确认和验证的需求阶段是关注符合记录要求。独立执行需求管理和计划阶段要求的有效管理和控制的不断变化的需求[39]。
图像
Figure.2。再保险流程模型描述(需求引出和开发)(需求文档)(确认和验证要求)和(需求管理和规划)
该模型主要有四个阶段,即;需求引出和开发,文档要求,确认和验证的要求,和需求管理和规划。需求引出和开发阶段包括需求分析和分配和流动的要求。需求包括识别的需求文档,软件和系统需求规范。确认和验证的需求阶段是关注符合记录要求。独立执行需求管理和计划阶段要求的有效管理和控制的不断变化的需求[39]。
该模型集成的所有重要方面重新进入软件开发过程,以找出有用的需求从各种来源。需求管理和规划阶段是在提出重新注册流程模型和与每一个软件开发过程相关。活动在提出模型如,启发,文档的要求,验证和确认,需求管理是紧密相连的软件开发阶段。此外,它可以帮助恢复和修改需求,当需求变化在开发和维护阶段。软件开发人员可以设计软件系统,它可以避免和管理模型的帮助下改变需求。

需求引出和发展:
需求引出和开发阶段主要侧重于研究和从不同的角度收集所需的要求和系统目标(如客户、用户、约束系统的操作环境,贸易、营销和标准等)。需求启发阶段始于识别系统的利益相关者和收集原始需求从各种观点。原始需求是要求尚未分析和写在最后的需求规范文档。启发阶段旨在收集需求从不同的看法等,业务需求,客户需求,用户需求、约束、安全要求、信息需求、标准等等。通常情况下,系统的规范要求开始观察和采访人。
此外,用户需求经常被误解,因为系统分析师可能误解的用户的需求。因此,要求发展需求的理解是必要的。除了需求收集、标准和约束需求开发中起着重要的作用。的发展需求可能语境系统开发。的绘画形式的发展要求是图3所示,系统分析师收集原始的需求从用户,然后执行详细的分析需求和接收技术开发人员的反馈。同时,从组织环境的约束也进行了分析。最后的结果与系统的专门性相比,即。,conversion of users’ requirement into technical requirement and produces good and necessary requirement for software development.
图像
Figure.3。发展的要求

需求分析:
需求分析是任何组织的基本活动在构建高质量的软件产品。这些要求那么严格的上下文中分析业务需求。我们也观察到,确认原料需求在本质上可能是相互冲突的。因此,谈判、协议、通信和优先级的原始需求成为需求分析的重要活动。分析需求需要记录,使与利益相关者沟通和未来的维护要求。软件需求分析过程涉及复杂的任务的抽取和记录干系人的需求。记录、分析和建模用户的需求可能是一个系统设计的基础。软件需求分析和软件项目开发文档过程是至关重要的。同时,它可以用来提炼需求系统的分配需求的分配在不同的系统或子系统元素。

分配和细化的要求:
需求分配和细化的主要目的是确保所有系统需求实现的子系统或一组子系统执行共同实现系统目标。顶级系统需求应该是有组织的层级结构,可以帮助在不同级别的查看和管理信息系统。要求分解到的系统级需求可以设计和测试。因此,分配和细化可能几个等级制度执行的水平。的详细级别增加随着工作的进行的层次结构。系统级需求在本质上是通用的。在低层次的需求层次结构非常明确。顶级系统需求中定义系统需求开发阶段,这是主要的输入需求分配和细化阶段。随着系统级需求正在开发,在层次结构中定义的元素也应该考虑需求分析。

的文档要求:
准备一个正式的需求文档在收集需求,其中包含一个完整的软件系统的外部行为的描述。需求开发过程是确定的活动,该系统将由软件的功能。非功能性需求与功能要求结合到软件需求规范的帮助下细化和配置要求。要求的文档包括需求识别与需求规范。建立软件需求说明书(SRS)为每个软件子系统、软件配置项,或系统组件。

需求识别:
要求识别实践关注每个需求的分配一个惟一的标识符。这些独特的标识符是用来表示在产品开发和管理要求。要求识别过程包括三个阶段,即;基本编号、标识和汽车的支持。基本活动包括大量非标准编号和编号,编号而识别活动包括标签,基于结构的识别和符号识别。汽车是用来支持和自动化管理系统项目,包括动态重新编号,数据库记录识别和基线的要求。
要求规范
成功后的SRS生产需求的识别。这是一个有效的文档要求规范,这是一个完整的描述系统的行为或软件开发。一般来说,目的的SRS是一个全面的描述和软件开发环境。SRS最小化所需的时间和精力开发人员实现期望目标,也有助于减少开发成本。良好的SRS定义了应用程序如何与系统硬件交互,其他程序和用户在各种各样的真实情况。等参数,操作速度、响应时间、可用性、可移植性、可维护性、足迹、安全和速度的复苏也在评估不良事件SRS。
需求验证和确认
一旦整个需求中指定的SRS,要求完成的协议涉及不同的政党。确认和验证活动包括验证系统需求对原始需求和验证系统需求文档的正确性。最常见的技术验证与涉众需求是需求评审,和原型。雷竞技苹果下载软件需求对系统级验证的要求。SRS的验证确保正确性、一致性、unambiguousness和可理解性的要求。需求验证和确认,要求之间的追溯机制可以产生一个审计跟踪软件需求,最后经过测试的代码。可追溯性应保持在系统级需求和架构的工作产品。软件需求开发阶段的结果是一个正式的文档包括一个基线同意软件需求。
需求管理和规划:
需求管理和计划阶段控制和跟踪的变化要求,同意要求之间的关系,要求文件之间的依赖关系等需求管理计划是一个连续和横截面的过程,从需求开发过程中识别和变更控制。此外,它是一个连续的活动,它可以执行后最终的开发和维护。需求可追溯性是需求管理的一部分,描述和遵循的生活需求及其与其他开发工具的关系向前和向后的方向。管理所需的不断变化的需求,因为这些是经常变化,造成过度伤害。不断变化的需求可以通过应用管理需求变更管理过程。它指的是管理能力要求在整个软件开发生命周期的变化。变更管理包括识别、分析,决定是否变更实施和实现的可能性和验证需求变更请求。
需求管理有时被视为最多方面的过程。一个需求变更可以在开发系统有很大影响,这是非常难以估计。对于每一个变化,成本和再开发工作之前一定要考虑批准。经过改进的需求,需求会进一步被纳入软件开发过程。需求管理工具已经开发管理不稳定的需求和需求工程过程中收集大量的数据。需求管理工具收集系统信息与系统要求在数据库或存储库,并提供一系列设施来访问的信息需求。软件需求管理工具支持安全、并发多学科开发团队成员之间的合作工作,支持标准系统,建模技术和符号。有必要维持一个审计跟踪的变化,档案基线版本,并与一种机制来进行身份验证和批准变更请求。一个也应该保持所有项目的全面数据字典组件和需求在一个共享库和生产预定义的和特别的报告。文档也应该能够生成符合工业标准模板。
流程模型实现各软件项目的研究生学生工作的最终项目工作组。此外,该模型也适用于各种管理系统。最后,我们发现,在采用这种模式,开发成本和时间相对减少。的成功实施也提出再保险过程可以产生好影响软件产品的生产质量。提出再保险模型可以用于大型软件开发过程的不断变化的需求。任何进一步的变化的组织可以允许用户在软件开发过程中需求。SRS能做出相应调整,这改变了需求可以在软件开发过程的要素。
安全需求工程(行为):
设计一个安全的软件设计师的软件系统是具有挑战性的问题。恶意用户总是试图打破系统,作为回应,软件厂商开始为他们的产品提供安全作为一个必要的功能和系统。各种强大的技术开发来解决一系列广泛的安全问题在过去的几年中。在选择安全措施,安全系统设计师考虑整个系统的设计,他们不把随机的安全技术。一般来说,开发者应用安全机制,例如,密码保护,防火墙、病毒检测工具等软件开发的实施阶段。这些安全机制很少考虑需求开始。因此,特定系统的安全需求和提供保护的基本服务和资产常常被忽视。
虽然,安全需求近年来给予重大关注,但缺乏上下文的操作。因此,安全性是过程呈现在图4中,纳入安全要求再保险的概念。再保险方面包括功能性和非功能性目标以及需求约束,而安全涵盖了风险分析和管理,它有四个维度,即;安全需求、安全目标、威胁和资产。这个过程包括安全机制之间的关系建立在非功能性需求的安全需求和规范的软件性能。提出了过程的最终目标是保证资产的威胁,它会破坏资产。安全目标的威胁可以逆operationalised的安全要求。本研究的目的是将安全重新集成到过程,以便安全软件产品生产的[40]。
此外,我们发现,在安全管理风险再保险再保险研究是一个伟大的挑战。的一个关键,一个好的业务领域之间的一致性和安全的结构是保持关注的资产业务,保持安全的各种风险。因此,提出了一种安全工程过程如图5所示,其中包含威胁建模[40]。威胁建模涉及理解系统的复杂性和识别所有可能威胁到系统,不管他们是否可以利用。提出了安全工程过程包括三个活动,即;风险识别和建模,选择安全要求和安全机制的发展。
在安全需求的形成,威胁可以根据它们的复杂性进行分析和决定是否减轻或接受风险的威胁。每个阶段的安全工程提供反馈之前的阶段,所有的早期阶段。反馈可以让设计师捕捉错误在早期阶段不让级联的影响。威胁建模和安全需求提供了基础,在此基础上构建安全系统的其余部分。识别威胁有助于发展现实的和有意义的安全需求。威胁的正确识别和适当的选择对策降低攻击者滥用系统的能力。安全再保险过程进一步探讨在图6中涉及组织模型。、业务模型和结构模型。商业模式包含了公司资产,如客户信息、用户账户管理、等等。然而,结构模型集成等资产,硬件、软件、服务器等。
图像
图。4。描述了两个主要的元素,如行为框架,(要求工程概念)和(风险分析和管理)
风险是潜在的问题可以来自于业务流程和威胁或损害组织的IT资产结构模型[40]。安全工程系统起着重要的作用在降低风险提供一些安全措施结构建模的业务组织[41]。
图像
图。5。威胁建模框架包括(威胁识别和建模)(安全要求)(开发安全机制)
图像
图6。风险管理框架包括(业务资产)、(it资产)和(风险)
信息需求工程(愤怒):
信息是软件开发的一个重要要求生成质量和更新软件。通常,开始观察和访谈信息的规范人们在不同的层次。收集到的信息流动在管理频谱决策软件开发。但仍有在再保险不存在这样的模型,从而为组织提供这样的支持。因此,我们提出了一种新的方法对信息需求工程(愤怒),这可以帮助软件开发人员为决策收集适当的和有价值的信息。拟议的方法包含了一些愤怒感知等,信息来源,信息处理的演员,他们的责任就是如图7所示。提出了愤怒的方法已经被更详细地描述我们的先前的研究文章[42]。
图像
图。7。愤怒的方法包含(信息处理演员)和他们的(责任)
事实的信息资源存储库,可以使用的信息处理演员。演员负责用户的组织有组织的信息处理和决策的责任。他们可以处理和分析信息根据的要求管理,不同的用户组或利益相关者。分析信息的需求是软件开发的一个重要的先决条件。系统的管理不断地决定了发展的基础上,分析了信息。同时,管理可以决定最重要的系统开发首先,然后是不太重要的子系统的帮助下提出了愤怒。
分析的过程中获得的信息在不同层次的管理范围检查,这可能会导致积极的改变/组织中修改。管理频谱信息工程组成的各种信息处理等演员,项目团队,项目管理小组,指导委员会,和战略规划小组。这些演员协助管理需要决定软件开发。项目团队的主要目的是收集信息从各种来源和分配它到下一个级别即。,信息系统设计师。信息系统项目管理小组负责管理独立项目。信息系统高级管理指导委员会主要是授权的系统开发。最后,演员在我们的方法的关键是企业战略规划小组,设计战略计划和决策。同时,他们为项目团队提供整体战略方向并解释信息系统项目利益相关者的重要性。
重新测量分析过程:
再保险的测量过程也可以提高用户参与和提高软件产品的质量。提出了研究分析提出的性能需求工程过程模型与现有模型。在文学中,Maculay和Kotonya——Summervillay再保险流程模型已经提出收集质量要求。Kotonya - Summervillay模型提出了一个概念性的线性流程模型,这表明迭代之间的一些活动,比如,启发和规范[19]。此外,活动在这个模型中相互重叠和经常进行迭代。Maculay模型提供了一个纯粹的线性过程,这是无法显示的重叠或迭代活动[45]。
虽然,一步一步执行的活动,但活动的顺序变得不规则。同时,适当的管理要求不执行上述模型。该模型描述的过程在本质上是线性和迭代的[39]。它由各种再保险没有重叠的阶段。在提出的模型中,它的任何阶段时开始前一阶段完全执行。结构化面试的帮助下进行了定性调查问卷找出之间的性能度量模型和现有的模型。为此,问卷被选为了收集大量的数据需要获得一个全面的理解过程。调查问卷由参与者的背景细节,公司和项目细节,再保险的过程,和RE技术(表1和表2)。
许多封闭式问题也被进行了问卷的长度最小化。使用开放式的问题,这是重要的参与者的答案在自己的文字里。参与者被要求完成调查问卷和添加任何额外的语言信息。访谈会话的使用允许参与者明确含义的术语和使用问题,确保他们有一个清晰的理解的被检查。面试大约30分钟的持续时间与时间的差异造成的附加信息添加口头的参与者和使用应急问题的问卷调查。
图像
表1在A公司和B公司的调查项目
采访发生在预定的时间在公司的私人会议室前提保持安静,undisrupted位置,为每一个面试是一致的。共有10个采访都是在两个不同的公司进行的,在生产经营和金融行业。
图像
参与者主要是在项目管理或业务分析师的角色,负责活动相关的项目。因此,提出再保险流程模型与现有模型相比,我们发现,模型强调每一个过程。也可以看出线性模型和迭代模型纯粹是能够执行的每一个活动过程(表3)。通过这种方式,提出再保险过程模型可以受益于线性的组合和迭代结构[43]。结果是基于案例研究的结果的三个不同的项目,在两个上述公司执行。
图像

需求建模框架:
大部分的需求文档都写在模棱两可的自然语言,不正式的,不精确的。同时,要求通常聚集在文本格式可能是模糊的,无法区分,有时,它可能被覆盖了。没有建模的需求文档、需求的认识是很难理解的。缺乏合适的建模框架的要求是本研究的一个重要问题。在学术界中,研究者提出了各种详细和集中发展模式要求。但大多数这些模型产生的学术研究太典型仅供实际应用和解决一些具体问题。因此,需求建模框架是如图8所示提供清晰的视图的用户和利益相关者的需求。它由五个主要阶段,即;可行性研究、需求收集和规范,对业务需求的分析,系统需求建模和系统设计。进一步,分析业务需求包括业务概念和协会,业务对象生命周期和业务任务和方法。 The system requirement modeling incorporates actors, use cases and their scenarios [44].

可行性研究:
可行性研究的目的是描述的优缺点提出的现有业务或系统。它还定义了该系统所需的资源和它的成功的前景。主要有两个标准来判断系统的可行性,即。,成本要求,另一个是要达到的值。因此,一个设计良好的可行性研究应该提供一个历史背景的业务或项目,产品或服务的描述,会计报表,详细的操作和管理,营销研究和政策、金融数据,法律要求和纳税义务。一般来说,可行性研究之前需求开发和项目实施。

需求引出和规范
需求引出和开发阶段主要侧重于研究和收集所需的要求。同时,它专注于目标系统从不同的角度[224]。需求启发阶段始于识别系统的利益相关者和收集原始需求从各种利益相关者。启发阶段旨在引起需求等各种观点和业务领域,业务需求,客户,用户,限制,安全,和业务标准等。此外,该规范的系统需求开始通过观察和分析需求与利益相关者访谈。用户需求经常被误解,因为系统分析师有时无法理解用户的需求
此外,标准和约束也扮演着重要的角色在系统开发和规范。因此,我们已经观察到再保险过程的主要目的是收集需求从客户和商业环境系统的方式。系统分析人员收集未经加工的要求,根据系统需求进行详细的分析。此后,然后将这些结果与最终的系统架构规范。SRS文档用于指定用户的需求。它描述了系统开发,而不是它的过程。此外,它包括一组用例描述所有与系统的交互,用户或软件。

分析业务需求
许多组织已经建立了他们的程序和方法进行业务需求分析,这可能是专门为业务优化组织[21]。然而,分析业务需求的主要活动是确定业务概念和协会,确定业务对象的生命周期,并确定业务任务和方法。

业务概念和协会
存在各种商业概念和方法论协会技术但是这些冲突在初始化的过程。在这项研究中,我们分析的起点应该是业务需求分析与其他系统元素及其关系。在业务概念和关联模型,系统分析人员可以应用简单的组织工作模型使用UML类名称和没有更详细的信息,对利益相关者的名字和他们的角色。这样的模型由业务分析师和领域专家讨论,通常不熟悉面向对象的分析和设计。因此,所有模型的其他元素,比如聚合、成分、概括、接口、枚举等,不应该被用于概念分析。它可以使UML新手理解有点解释后的过程。此外,分析师可以提供文本描述这些概念和生成可打印或通航领域词汇表。因此认为它应该的根工件过程中,哪些应该被用于定义其他需求模型元素、用例等。

业务对象生命周期
要求模型可以使用在需求收集过程中或在系统分析。诱发需求被认为是一个单独的活动或系统分析的一部分。正确的重要性要求必须为系统开发是一个高优先级。建立准确的需求模型意味着需求的正确性的保证。要求模型还可以用来发现软件和业务系统的功能和数据要求[44]。此外,模型可以作为规范要求系统的设计者和开发者。组织有自己的业务规则来管理业务对象。在很多情况下,业务规则规范业务对象状态改变的重要性。需求建模的一个重要工具来理解这些变化[44]。
美国也是一个术语的一部分,它可以用在其他业务和需求模型。应该创建状态机图只对那些有动态状态的业务概念。业务建模者应该定义触发器状态转换图。在业务建模转换触发器,大多数人使用非正式的信号,在大多数情况下,对应于业务角色的行动。同时,时间和属性改变触发器用来表达各种状态变化根据时间或数据基于业务规则。因此,有可能定义内部触发内部发生的一种状态,它不改变[44]的过渡。
图像
图8需求建模框架描述(需求引出和规范)(业务需求分析)(系统需求分析和建模)(系统设计)

业务任务和方法
后学习领域术语和业务规则关于业务对象的生命周期,分析师可以识别业务任务和方法,和关联角色过程中涉及[45]。在这个过程中,设计师需要视觉上单独的系统参与者和用例。业务角色协会在专业业务流程可以执行最佳用例图或可编辑的关系矩阵。的第一步从业务分析需求定义是用例分析[44]。
业务流程建模通常是在两个方面,即:”,“和”是“[44]。“是”表示当前形势下,“将来”,代表目标情况后应达到自动化或重构[10]。对于软件开发人员来说,识别目标业务的各个部分,实现用户的网站,更重要的是定义业务任务和方法。
系统需求分析和建模
需求建模是一个重要的活动过程中结构设计和管理要求。需求建模有助于需求工程师理解结构和协助分析业务需求,与信息技术相关的需求,反之亦然,从而他们可以促进组织的业务- it的对齐。基本上,它包括演员、用例和场景,下面的小节中讨论。
演员:
一个演员是一个负责任的用户或外部实体,它可以与系统或产品。与此同时,一个演员是与系统交互的外部系统。演员可能是一个人类用户或另一个系统,和有一些目标和责任,以满足与系统进行交互。也需要生成演员,谁给了紧凑的整个模型的概述。此外,准备必要的要求规范模型也包含包细节图显示包的用例,它们与演员协会,用例之间的关系。良好的建模要求,系统工程师准备活动图,可以可视化场景复杂的用例。在需求模型中,应该适当的用例和内嵌套的活动分配作为他们的行为。最后,不同的演员参与需求建模用例中描述可以根据预定义的模板,即。rational统一过程,用例文档,和演员函数等。
用例和场景:
用例描述的一系列潜在的软件需求模型和外部利益相关者之间的相互作用。UML的用例图是一种行为图定义和创建用例分析。用例的目的是提供一个图形化的概述的功能要求,由一个系统提供的演员,他们的目标,任何用例之间的依赖关系。此外,它是有用的描述每个演员的系统性能。一般来说,要求模型是用来捕获最终用户需要从系统功能要求。等其他需求、非功能性需求或详细的功能需求无法捕获在标准需求建模图。最简单的方法是描述这些要求以简单的文本格式,包括用例的引用、场景等[44]。
另一种方法是创建特定需求建模引入刻板印象重要要求以及标签要求组成的特定的信息和定义类型的链接等跟踪需求,推出,满足,和支持。的数据结构的定义,系统分析已经完成,也可以包含在需求建模。类图中使用的对象图也可以为解释或定义样品测试的数据结构。与概念分析,更多的元素也用于用例场景,如,属性和关联,最终规范,列举和概括。尽管这样的模型被认为是设计的一部分,通常可以创建和维护的系统分析师。对于以数据为中心的应用程序,执行数据流图是很重要的,这是显示不同分类器之间的信息流动,即。,系统上下文图。它表明信息来自系统外部世界的实体,即。、演员或外部系统需要集成[44]。
前面的需求建模工件的系统分析师可能是负责用户界面原型。原型本身理论上可以映射到UML组合结构图。然而,尽管专注于单独的屏幕原型,人们有时宽松的屏幕,可以使用每个演员和有可能从每个屏幕导航到另一个屏幕。为获取这些信息,也可以创建GUI的导航地图。最后,我们强调需求分析工作可以在迭代和增量模型从而可以消除歧义在利益相关者的要求。需求建模的任务可能会不同,使用不同的方法[44]。
系统设计:
需求分析和建模阶段成功完成后,该草案要求可能提供给设计团队。设计团队检查的有效性草案要求,开始设计系统或软件模型。基本上,系统设计的过程设计、开发和实现该系统按照要求在现有系统的分析获得。系统设计的主要目标是发展最好的设计按照要求从用户操作软件系统和工作环境。系统设计是一个过程,定义体系结构、组件、模块、接口和数据系统,以满足指定的需求。UML面向对象的分析和设计中被广泛接受的建模软件需求和越来越多的用于设计非软件系统。后系统模型的设计,设计师对设计模型的效率。如果任何修改仍然是模型中,设计师再次检查的有效性要求,要求修正与评论。过程将停止,直到明确澄清不是由设计团队接收。
许多组织已经开发了他们自己的程序和方法进行业务需求分析,这可能是专门为企业组织优化。在上述框架,分析业务需求的主要活动是确定业务概念和协会,确定业务对象的生命周期,并评估业务任务和方法。同样,等因素,识别利益相关者,获取利益相关者的要求,分类,解释,记录需求有助于创建需求模型。此外,需求建模的实现各种需求分析的目的,和常规要求模型映射到系统元素。

讨论
我们提出了各种各样的需求工程方法,即,有效需求工程过程需求收集和管理,行为,愤怒,等等,可以有利于软件产业,开发安全、更新和激动人心的软件产品。通过应用这些方法,针对上述prctices,行业可以克服技术问题相关的需求收集、需求管理和需求的安全。

结论
再保险是一个必要的活动的软件开发过程设计和开发高质量的软件产品。摘要社会、组织和技术问题进行了讨论,同时,安全SRS文档中也观察到的影响。的有效的再保险过程模型,提出了包含迭代哲学进行更好的需求分析和处理。该流程模型有利于以后维护以及需求原型与更多的用户输入。此外,安全性要求工程(行为)与风险管理流程设计和插图开发安全软件产品。此外,信息需求工程(愤怒)方法已经开发了更好的信息收集和决策。此外,提出再保险的性能度量过程模型提出了实用性的商业组织和社区信息系统的用户。同样,一个需求建模框架旨在理解利益相关者的不同观点从而模糊需求可以最小化。
总之,上述再保险prctices可以用来制造有效的过程,可以用于软件开发过程产生高质量的软件产品。

引用
  1. p . Jalote集成的软件工程方法,第二个印度版,Narosa出版社,新德里,2010。
  2. s . Wahono分析需求工程问题,IECI日本车间、日本(2009)55-58。
  3. b . Nuseibeh和伊斯特布鲁克,要求工程:一个路线图,在IEEE Proc. Int。Conf.柔软。Eng。ICSE 35-46 (2010)。
  4. d·l·帕尔曼党注册,软件工程不是计算机科学项目,安。软Eng。,6(1) (2009) 19– 37.
  5. 威廉姆斯和肯尼迪,一个框架,用于改善需求工程过程的有效性,计算学院的信息系统和管理,伦敦,2007年。
  6. Standish Group。混乱的报告。丹麦语,MA: Standish Group, 2004年。
  7. s . l . Pfleggeer软件工程理论与实践,Prentice Hall,新泽西,2008。
  8. d·j·赖夫需求管理:寻找涅槃”,IEEE软件(2010)45-47。
  9. Baumert Whinney,软件测量和能力成熟度模型,软件工程研究所技术报告,2002。
  10. 的野外研究皮肤等大型系统设计的软件设计过程,沟通的ACM, 31卷,11 (2003)1268 - 1287。
  11. 伊曼,哈立德和Madhavji工程实践领域的研究要求在信息系统开发中,第二IEEE国际研讨会Proc.再保险公司,英格兰(2004)68 - 80。
  12. Siddiqi等,要求工程:新兴智慧,IEEE软件,13卷,2号(2010)15 - 19。
  13. Nuseibh,巴沙尔和史蒂夫,需求工程:一个路线图,Proc. 22日国际会议的先进信息工程、纽约,ACM (2010) 35-36。
  14. 索耶和皮特、包软件:挑战再保险公司Proc.第12届国际会议在先进的信息系统工程,瑞典,施普林格(2011)137 - 142。
  15. 埃曼和Madhavji再保险的野外研究实践在信息系统开发中,Proc.再保险的05年,纽约(2005)68 - 70。
  16. 触底,Potts和里希特,审核状态的实践需求建模,Proc.再保险的93年圣地亚哥(2008)2 - 14。
  17. 美国Sindre, a . l . Opdahl误用例描述模板,Proc.第七届国际研讨会再保险公司瑞士(2011),23-31。
  18. Kusiak和唐,创新需求生命周期框架,Proc.第五int.研讨会上智能制造系统,伦敦(2010)61 - 67。
  19. g . Kotonya,伊恩,集成安全分析和需求工程、Proc.第四届亚太软件工程和计算机科学国际会议上,中国(2011)259 - 271。
  20. ——软件过程评估-第7部分:指导用于过程改进,技术报告,瑞士,2009。
  21. k . Wiegers软件需求,微软出版社,美国,2009年。
  22. Kauppinen等,实现需求工程过程中组织”,成功因素和挑战,爱思唯尔科学,允许转载的信息和软件技术(2004)937 - 953。
  23. b·柯蒂斯软件过程改进:方法和经验教训,Proc.第九届国际会议在软件工程中,(ICSE 1997),中国(2009)624 - 625。
  24. 迪亚兹,M。,and Sligo, J., How software process improvement helped Motorola, IEEE Software, Vol. 14, No.5 (2011) 75–81.
  25. b . McFeeley理想:软件过程改进的用户指南,手册μ/ sei - 96 hb - 001,匹兹堡卡内基梅隆大学软件工程研究所PE、美国,2006年。
  26. 美国,软件过程改进:实用指南业务成功,5日,addison - wesley,哈洛,英格兰,2008。
  27. k . Wiegers软件需求,微软出版社,雷蒙德,佤邦,美国,2009。
  28. p . Zave分类研究工作的再保险,ACM计算机调查(2007)313 - 314。
  29. c . Kuloor和a . Eberlian需求工程软件产品,加拿大卡尔加里大学(2011)1 - 12。
  30. Palayger Bhavani,测量和影响需求工程过程质量组织,信息和通信科学、Mcqurie大学,澳大利亚,2009年。
  31. k . Wiegers需求工程的现实世界,Requirenautics季度(2004)- 58。
  32. h·赫克特和m . heccht要求可靠的软件有多可靠?美国,雷德蒙德微软出版社佤邦,2004年。
  33. 萨默维尔和g . Kotonya需求工程过程和技术,EnglandWiley, 1998年第1版。
  34. c . s .屈尔改善通过一个操作的应用系统需求质量概念的过程:一个至关重要的元素在系统维护,微软出版社,雷蒙德,佤邦,美国,2000。
  35. Dhirendra Pandey, Ugrasen Suman, a . k . Ramani问题和需求工程实践的影响在设计高质量的软件产品,Proc.全国性会议的一部分未来的IT系统,DAVV,印多尔(MP) (2011) 44-46。
  36. Dhirendra Pandey, Ugrasen Suman, a . k . Ramani角色需求收集的采访,Proc.国家智能计算与信息系统会议上,d . p . Vipra大学,比拉斯布尔(2009)26-31 (CG)。
  37. Dhirendra Pandey, Ugrasen Suman, a . k . Ramani社会组织参与需求工程过程的困难,软件工程杂志,BioInfo出版物,孟买,1卷,1号,ISSN: 2229 - 4007 & ISSN: 2229 - 4015 (2010) 01-05。
  38. Dhirendra Pandey, Ugrasen Suman, a . k . Ramani需求规范文档进行的设计和开发高质量的软件产品,国家会议Proc.智能计算& d . p . Vipra大学,比拉斯布尔(2011)43-47 (CG)。
  39. Dhirendra Pandey, Ugrasen Suman, a . k . Ramani有效需求工程软件开发过程模型和需求管理、国际会议Proc.最近通信和计算机技术的进步,ARTCom”2010年IEEE计算机协会,2010年,ISBN: 978-0-7695-4201-0,喀拉拉邦(2010)287 - 291。
  40. Dhirendra Pandey, Ugrasen Suman, a . k . Ramani安全需求工程开发安全软件框架,计算情报和信息安全的国际期刊,IJCIIS,澳大利亚、卷。1 8号,ISSN: 1837 - 7823 (2010) 55 - 65。
  41. Dhirendra Pandey, Ugrasen Suman, a . k . Ramani安全性要求工程风险管理中的问题,国际计算机应用》杂志上发表的计算机科学的基础,美国,ISBN: 978-93-80747-89-4, 17卷,5号(2011)11 - 14号。
  42. Dhirendra Pandey, Ugrasen Suman, a . k . Ramani“工程”信息的要求,Proc. IEEE国际会议信息安全和应用程序,ICISA, 2011年,ISBN: 978 - 1 - 4244 - 9223 - 7/11,韩国,2011年。
  43. Dhirendra Pandey, Ugrasen Suman, A . k . Ramani”性能测量不同的需求工程过程:一项研究”,计算机工程和技术的国际期刊,IJCET, Tamilnadu, ISSN: 0976 - 6375, 1卷,2号(2010)286 - 300。
  44. Dhirendra Pandey, Ugrasen Suman, a . k . Ramani“框架建模软件需求”,国际期刊的计算机科学问题,IJCSI,马来西亚、ISSN: 1694 - 0814, 8卷,第3号(2011)164 - 171。
  45. l·a·麦考利,需求工程,斯普林格出版社,2006年版。
  46. j . h . Flavell元认知和认知监控:认知发展研究的新领域,美国心理学家杂志(2011)906 - 911。