INFO4MYSTREY

This blog is created for educational purposes. Info4mystery archive and support student, teacher, Educationalists, Scholars and other people for learning by facilitating reflection, questioning by self and others, collaboration and by providing contexts for engaging in higher-order thinking.

Post Page Advertisement [Top]

Requirement engineering process models

Requirement engineering process models


Abstract:
The requirement engineering shows different models of requirements processing technique. The process models assortment from linear to iterative in configuration. The goal of Requirements Engineering is introducing the engineering principles in the practice of traditional analysis of information systems. Therefore, one is must follow a systematic and disciplined process. The Requirements Engineering process must therefore, it consists of structured and repeatable tasks. The requirement engineering is the most effective step in the software development process. Its goal is to collect a good obligation from stakeholders in the right way. It is important for any organization to develop high quality software that can meet the needs of users. The technology needed for software development process is a complex exercise that considers the needs of the products from a wide range of perspectives, roles, responsibilities and goals. Therefore, it is necessary to apply the necessary technical skills in any part of the software development process. In this paper, invite an effective model of process technology to produce quality requirements for software development. Management and planning are enforced individually for effective management of requirements. It is recurring in nature for better requirements engineering and later maintenance. The successful implementation of the proposed requirements engineering processes can have a major impact on the production of high-quality software products.
Introduction:
The requirement engineering is the most impressive step in the software development process. The intention is to collect a good requirement from investors in the right way. It is important for any organization to develop high quality software that can meet the needs of users. The technology needed for software development process is a complex exercise that contemplates the needs of the products from a wide range of perspectives, roles, responsibilities and goals. Therefore, it is necessary to apply the necessary technical skills in any part of the software development process. As a result, it is able to recognize problems and suggestions for improvements in the process of the requirement engineering open a momentous prospective for increasing the success of software projects. To improve the process of requirement engineering, current practices must be evaluated. Understanding and modelling the current process of requirement engineering is an important step towards improving requirement engineering practice and thus enhances the success of software projects. The requirement engineering is a very significant activity, which can change the whole project activity on software development. The Requirement Engineering is one of the most important tools for collecting requirements, studying and documenting requirements.
The engineering requirements are the initial part of the process of software engineering, which collects, understands and defines user requirements. Requirements engineering is acknowledged as a crucial task because many software failures fail, from incomplete or simply incorrect specifications that are requisite as a result. Several of the most common, the most serious problems connected with the development of software to the associated needs.
Requirement Engineering Process
There are following requirement engineering process.

1. Requirement Elicitation and Development
The quality of the software depends on the requirement elicitation, requirements analysis and management requirements. Requirement elicitation and development phase of the research is the collection of requirements and the desired objectives for the system from different perspectives. Requirements elicitation is about grasping the problem. In conventional, the analyst's requirements are not a specialist in the domain model. By collaborating with specialists in the domain, he has to construct himself rich enough model of that domain. The realism that the various disciplines are involved in this process make difficult the things. In several cases, the analyst not only modelled an external observer model, merely eliciting details from the domain specialist.
       ·        Requirements Analysis:
The development and recruitment of good quality requirements is the primary task of any organizations develop quality software products. These requirements are thoroughly investigated in the context of business requirements. Also examine that the identified basic requirements may be contradictory. Therefore, the consultations, agreements, communication and prioritization of basic demand have required an important task of the analysis. Rated the requirements must be documented to require communication with stakeholders and future maintenance and enable the system. Check also requirements in evaluating the delivery of software and development process models, data and domains of behaviour that can be handled by software. Priority to the requirements of the software is also part of the analysis of software requirements.
     ·        Allocation and Flow-down of Requirements:
The reason of the requirements allocation and Flow-down is to ensure that all system requirements are met by a subsystem or through a set of subsystems that can work together to achieve these goals. Hierarchically organized with the system level requirements that can help to view and manage the information at different levels of abstraction. The requirements are analyzed to the level at which the requirement can be designed and tested. Thus, the allocation and flow down rate can be performed for different hierarchical levels.
2. Requirements Documentation
A formal document has been prepared after collecting requirements, which contains an entire report of the appearance of the software system. The development process of the requirements is the activity to conclude which features of the system software. The non-functional requirements in combination, with the functional requirements of software requirements Specifications with the help of flow down, the allocation and derivation. A specification of the software requirements is entrenched for each software, software configuration object subsystem or part of this phase. Included in the documentation of the requirements are the identification of requirements and specification of requirements.
·        Identification of requirements:
Identification of requirements is committed to assigning an exclusive identification code for each requirement. The exclusive identifier is used to specify to requirements for the period of development and product management. The identification process consists of three auxiliary activities. One of the numbering activities of the important figures and non-significant numbers as identification includes labels, identification based on a structural and emblematic identification. The last method is to support and automate the management of items that consist of dynamically renumbered, identity database recognition, and the requirement of placement of the base.
·        Specification of requirements:
Once you recognize the problem, have to illustrate it in the documents requirement specifications. This document elucidates his product to deliver, not the process of how it was built. The document elucidates the requirements were made after successful identification requirements. Document elucidates the product to deliver than the process of its development. The Software Requirements Specification (SRS) is an impressive means of developing the requirement specification for a complete description of system or software behaviour. It comprises a set of use cases that elucidate all interactions available to users on the system. SRS provides a complete description of what the software will do and how to do it. An SRS reduces the time and effort required by the developers to accomplish the desired goals and also reduces the development costs. A good SRS refers to how an application will communicate with system hardware, other programs and users in a wide range of real-world situations. Framework such as speed of action, response time, availability, portability, maintenance, footprint, safety and speed recovery of side effects were appraised SRS.
3. Requirements Verification and Validation:
If all requirements are elucidated and defined in the SRS, the different parties concerned must agree on their nature. Please bear in mind that the correct conditions are validated and these requirements are included correctly verification. The activities include validation and verification, validation system requirements against the basic requirements and validation of the accuracy of the requirement documentation by the system. The most common method for validating is the requirements analysis with stakeholders, and prototyping. Validation and Verification, Require Traceability Mechanism can generate a control track between software requirements and finally tested. The supervision must be mandatory to keep the system level, between the software requirements and the last part, products made of architecture. The outcome of the necessary software development required a formal document with an agreed basic software requirement.
4. Requirement Management and Planning
Requirements management and planning phase control and observe changes of the agreed terms, affiliations between requirements and assurance between the requirements document and other documents that occur during the system and software engineering process. It is an uninterrupted cross-section and processes from requirements management planning and ongoing activities of recognition and change organize during and after the process requires development phase. Management requirements are a continuous activity that can be executed after the development and retention period required can continue to change. 
Comparative Analysis:
          Comparative analysis between the proposed models is discussed in this paper. There is a new phase called traceability, focusing on undetermined barriers, that involvement of users is the center of interest. Our proposed model of the first goals is defined. The objectives are linked to existing and valid barriers. The built-in barriers and non-binding restrictions are the stage in which they shorten and each other. The incompatibility takes place in relation to both existing and valid barriers. The incompatibility can be resolved in stages of binding and non-binding restrictions.
The incompatibility cannot be solved by binding and non-binding phase, called insurmountable incompatibility that appears at the stage of traceability in the involvement of users in the study. The incompatibility is caused by the binding and non-binding was agreed to use to resolve them. The actual goal is to try and enable the many incompatibilities that is solved the successful requirements engineering process and that will actually help the developers to build up the right product.
The modification of previous models did not participate in the investigation into the incompatibility that undetermined incompatibilities that are vital for the success or failure of the system can be ignored. Our goal is to address the undetermined incompatibility and study the significance of this requirement to cause incompatibilities in the eyes of the user and to solve it.
Conclusion:
 In this paper, broach an imposing model of process technology to produce quality requirements for software development. Supervision of management and planning phase is enforced separately for impressive management of requirements. It is recurring in nature for better requirements engineering and later maintenance. The successful implementation of the broached requirements engineering processes can have a major impact on the production of high-quality software products. The requirements engineering plays an important role in the success or failure of software products. If it is well done it will eventually help develop good software. The user must actively require process technology; User involvement is foremost to the success of software products. The administration needs is a crucial phase of the process technical requirements. The traceability is the procedure keeping the traces of the requirements from idea to implementation, used to determine the effect that one of the many traceability applications when requesting change is requested. Requirement management is no possible without traceability.

References


[1]
M. Hafeez, F. Rasheed and M. Khan, "An Improved Model for Requirement Management System," Information Technology & Software Engineering, vol. 7, no. 1, 2017.
[2]
D. Pandey, U. Suman and A. K. Ramani, "An Effective Requirement Engineering Process Model for Software Development and Requirements Management," in International Conference on Advances in Recent Technologies in Communication and Computing, 2010.
[3]
S. Martin, A. Aurum, R. Jeffery and B. Paech, "Requirements Engineering Process Models in Practice," AWRE’, pp. 141-155, 2002.
[4]
D. Pandey and V. Pandey, "REQUIREMENT ENGINEERING: AN APPROACH TO QUALITY SOFTWARE DEVELOPMENT," Journal of Global Research in Computer Science, vol. 3, pp. 31-33, 2012.
[5]
D. S. Asghar and M. Umar, "Requirement Engineering Challenges in Development of Software Applications and Selection of Customer-off-the-Shelf (COTS) Components," International Journal of Software Engineering (IJSE), vol. 1, no. 2, pp. 32-50.



No comments:

Post a Comment

Popular Posts

Bottom Ad [Post Page]

| Designed by Colorlib