The Development Process of Software - Research Paper Example

Software Requirements Introduction In the development process of software, requirements’ gathering is initial and vital step. The whole is based upon the gathered requirements, so the criticality of collecting accurate and exact requirement has a great impact in software development. Requirement Engineering Process Model (REPM) and Twin-Peak Model (TPM) are two main techniques discussed in the given articles. Requirement Gathering Techniques Requirement Engineering Process Model (REPM) developed for the development of software and the management of requirements. According to Pandey et al., (2010) the proposed method for the collection procedure of requirements has some factors involved in it. The process of development of requirements consists of the basic and initial level of raw requirements collected for development of software. These raw collections of requirements are taken from the customer or client of the software, who is interested in the development of the software. The early requirements are usually in the form of simple statements described by a client. These are written mostly informal ways as told by the client. The great and vital factor for requirements gathering is the technical aspect in which system is going to develop. This factor has a high scope for requirements gathering procedure. Finally, three factors have an impact on gathering of software’s requirement, the client, the environment, and the technicality of system that needs to develop. In addition to this factor, environment is itself a factor, which is involved in the making procedure of developed software. The method of elicitation of requirements is considered as the first step for collection of raw requirements. The Requirement Engineering Process Model (REPM) presented restrains various important and useful features for requirements gathering. According to the proposed model requirement elicitation, includes different kinds of important features. The requirements that are related to a business for which system is designed are important to know. These requirements involve around the demands of the business. The significance of the requirement is decided according the demand of business. These business needs will help in the process of prioritization of requirements. Along with the core business requirements, requirements that are directly useful for customers are equally important to gather. The requirements about how customer or end user will interact with the developed system are collected. These requirements create the basic structure of the system that how it will look like after final development. These are collected from the end user that describes the traditional way of work flow and procedure and finally, this will become the raw data for requirements gathering process. Requirement elicitation procedure also concerns about the requirements related to the security. The handling of security issues is highly important for a perfectly developed system. For this reason, the security related requirements for the system are collected from the start of requirement gathering process. The standards of information systems and communication networks are also included in the gathering procedure of software requirement because the standards are necessary to follow and implement in the developed system. Some standards contain constraints, which are essential to implement and have a positive result for the system going to be developed. The combination of all assemble requirements in raw format is forwarded to the next step for the development of the software system. The proposed model is useful for iterative development that accepts changes. This model is harder to deal with some other types of software development life cycle, and this is considered as the limitation of the proposed model (Pandey et al., 2010). The proposed model of Nuseibeh (2001) is based upon the concept of Twin Peaks Model (TPM). According to this model, requirement specification and design part of the system are handled in the same time, which result into attaining the perfect system requirements. The equal focus is given to both types of the system. The model accepts changes that emerge from the system at any stage. For this reason, it is useful for the handling of requirements management that deals with changes. The Twin Peaks model (TPM) has commonalities with Extreme Programming (XP). The front end activities of the software project are handled through the Extreme Programming (XP). The scalability is harder to achieve while working with the Twin Peaks concept. The working procedure of Twin Peaks Model (TPM) is followed by the iterative development. For large scale projects use incremental process of software development because for such systems the proposed concept is difficult to manage accurately and effectively. The Twin Peaks model (TPM) has some conceptual differences. Through Twin Peaks model (TPM) concept the real world is elaborated simultaneously. For small scale software development this procedure is extremely beneficial and perfect but as the system grows to the larger it increases the difficulties for handling of both activities at the same time. Road for processing of development of software is constructed from requirement to design by Twin Peaks model (TPM). In this way of development working at the same time helpful for the tight budget and schedules. Due to the handling of the iterative nature of development, it accepts changes and possible to provide good reasons for the change management of the software requirements. From the results obtained from Twin Peaks model (TPM) developers could have a better understanding of a system and it defiantly results into the quick and accurate working of a developed system. Some questions are raised as limitations of the Twin Peaks model (TPM) has from an architecture point of view as there are no clear questions available about the choice of selected style of architecture. The classes of requirements are not positioned in a stable form and also harder to distinguish among them. The Twin Peaks model (TPM) accepts those changes occurred in the requirements, but the impact analysis is not performed for the proposed model that is having a big deal for the software change management. The product lines and product families can provide the stability factor for the software requirement. They support the change management process of the requirements. Commercial off-the-shelf software (COTS) systems are working upon the identification and comparing with the available architecture of the system with the requirements. These features cover the volatility of the software requirements and provide a stable system (Nuseibeh, 2001). Conclusions: The requirement gathering techniques that provide baseline for the development of software are described in the provided articles. Requirement gathering techniques are presented in detail including the positive aspects and limitation of applied technique. References: Nuseibeh, B. (2001). “Weaving together requirements and architecture”. Computer, 34(3) pp. 115–119. Pandey, D., Suman, U., & Ramani, A.K. (2010). An Effective Requirement Engineering Process Model for Software Development and Requirements Management. 2010 International Conference on Advances in Recent Technologies in Communication and Computing. Read More