System Requirements Engineering in Complex Situations Essay

Introduction

The Problem

The development of system requirements in a complex situation is a difficult endeavor. In complex situations, there are many challenges that affect requirements engineering. For instance, applicability challenges are experienced in the Traditional Requirements Elicitation Processes (TREPS).

Katina, Keating and Jaradat (2014) developed the article to examine the requirements in detail and to provide a framework that can be applied to assist in the evaluation of the system problems and the shortcomings of TREPS in highly complex situations.

Literature Review

There are various works that have been put forward that provide the general overview of strengths and weaknesses of requirement elicitation. The authors recognize the complexity that relate to system requirements in highly complex situations. For example, Alexander and Robertson (2004) stated that “the challenges of system requirements can be dealt with by incorporation of the system environment” (p. 24).

Methodology

In order to provide a succinct view, Katina et al. (2014) explored various dimensions of system requirements. This included nature of system observer, the attributes of system requirements in complex situations, nature of complex system requirement environment and the use of the TREPS in Vee model sample. The vee model sample entailed the integration of the technical aspects of the project cycle.

Findings

The systematic analysis of the various components resulted in requirement elicitation in complex situations. There are three phases that are important in requirements elicitation (Katina et al., 2014). Figure 1 is a summary of the three phases.

Conclusion

Complex situations should be based on the understanding that requirements can change and that they will change when new knowledge emerges from the system context.

2nd Reading: Requirements Engineering

The Problem

Across the globe, organisations want to improve their ability to carry out requirements engineering. The main goal of the organisations is the endeavor to find out if they have been successful in their efforts. As a result, the companies carry out assessments that target either the requirements process itself or the primary product of the requirements process.

However, good performance on either process is not an outright indicator of true success. Thus, Gorschek and Davis (2008) address the issue of the determining success in relation to requirements engineering.

Literature Review

The main aim of process engineering is to increase the chances that the built product meets the customer’s needs. According to Gorschek and Davis (2008), “engineers and researchers normally make changes to their processes in anticipation to achieve positive outcomes” (p. 69).

For instance, Davis and Zowghi (2006) noted that that there are five levels of quality in which dependent variables reside. Other researchers have also established the five levels. They include requirement phase, project, product, company and society.

Methodology

In order to address the issues that relate to the determination of success, Gorschek and Davis (2008) presented the framework that is suitable for assessment of requirements process. This entailed development of a framework for dependent variables and provided measures that can be applied for each dependent variable in order to determine success.

Findings

The authors established that there was the need to move beyond the traditional boundaries. This can be achieved by utilisation of multidisciplinary nature of requirements engineering. In addition, Gorschek and Davis (2008) established the need to invent new dependent variables and to map dependencies between levels. This will ensure that the ‘right’ requirements are established.

Conclusion

Software engineers, marketers, and managers should share the development responsibility in order to guarantee success and reduce the failure. The sharing of the responsibilities should enhance the monitoring of depended variables.

3rd Reading: Requirements Traceability

The Problem

There are many components of software development. One of the components is software traceability. The popularity of the requirements-to-code traceability has grown tremendously. However, there are no known benefits (Mader &Egyed, 2015). Thus, the aim of the study was to evaluate the significance of the requirements traceability.

Previous Studies

There are any studies that have been undertaken that relate to requirements traceability. However, most of the studies have concentrated on understanding the scope of requirements traceability. They have not explored the benefits of traceability. Mader and Egyed (2015) reviewed various studies and established that there are no works assessing the effect of traceability in the software development and maintenance.

Methodology

To investigate the benefits of the requirements traceability, Mader and Egyed (2015) conducted a controlled experiment. The experiment included 71 subjects that were involved in re-performing maintenance tasks. The tasks were divided into two categories. Half of the tasks had traceability while the remaining did not have.

Findings

The requirements traceability increased efficiency. In addition, it was found that it has an important role in improving the quality of maintaining software. For instance, the subjects with traceability were found to perform 24% faster in the identified tasks compared to the control group. In addition, the experiment group created 50% more correct solutions.

Conclusion

Traceability helps in the facilitation of higher performance, and hence it improves the quality of software maintenance.

4th Reading: The Role of Requirement Engineering in Software Development Life Cycle

The Problem

Requirements engineering plays a critical role in the software engineering. According to Chakraborty, Baowaly, Arefin and Bahar (2012), errors produced at the requirements engineering can be very costly if they are not detected at the early stages of the software development.

There are approaches used to appropriately capture the requirements in the software development. Therefore, the article presents the capturing procedure that can be used to enhance requirements engineering methods.

Literature Review

There are three types of models that describe a system. They include object model, dynamic model and functional model. The object model describes the static structure of the object. Furthermore, it is concerned with the relationship between the system and the object. The dynamic model is concerned with the interaction among objects. On the other hand, the functional model describes the data transformation in a system (Chakraborty et al., 2012).

There are many methodologies that are applied to construct the different steps of SDLC. For instance, Bruegge and Dutoit (2003) defined object oriented as “Object-Oriented = Objects + Classification + Inheritance + Communication” (p. 4).

Methodology

The author applied a hospital case study. The hospital presented a complex system situation. The analysis of the case study was based on VORD method. “The principle of the VORD method is the requirement detection and analysis that helps in translating the analysis into object” (Chakraborty et al., 2012, p.725).

Findings

The appropriate approach for capturing the needs of the users is the domain approach. It is critical in reducing errors as the development progresses to the next step and hence reduces the cost of development and maintenance.

Conclusion

The software development requires effective analysis. Chakraborty et al. (2012) added that there is the need for further studies to investigate the measures needed critical stages of SDLC.

References

Alexander, I., & Robertson, S. (2004). Understanding project sociology by modeling stakeholders. Software IEEE, 21(1), 23-27.

Bruegge, B., & Dutoit, A. (2003). Object-oriented software engineering using UML: Conquering complex and changing systems. Englewood Cliffs, NJ: Prentice Hall.

Chakraborty, A., Baowaly, M., Arefin, A., & Bahar, A. (2012). The role of requirement engineering in software development life cycle. Journal of Emerging Trends in Computing and Information Sciences, 3(5), 723-729.

Davis, A., & Zowghi, D. (2006). Good requirements practices are neither necessary nor sufficient. Requirements Engineering, 11(1), 1-3.

Gorschek, T., &, Davis, A. (2008). Requirements engineering: In search of the dependent variables. Information and Software Technology, 50(1), 67-75.

Katina, P., Keating, C., & Jaradat, R. (2014). System requirements engineering in complex situations. Requirements Engineering, 19(1), 45-62.

Mader, P., & Egyed, A. (2015). Do developers benefit from requirements traceability when evolving and maintaining a software system? Empirical Software Engineering, 20(1), 413-441.