A Risk Model of Requirements Change Impact Analysis

Rahman, Marfizah Abdul; Razali, Rozilawati; Singh, Dalbir

doi:10.4304/jsw.9.1.76-81

Cited by 10 publications

(9 citation statements)

References 23 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…The qualitative part consists of literature review and focus group study which have been conducted earlier to gather the identified risk factors as well as to confirm them. The findings have been reported in [19]. However, the findings from empirical study was only validated solely through opinion-based perspective, thus it should be refined and strengthen further by confirming the risk factors quantitatively through a large scale survey.…”

Section: Methodsmentioning

confidence: 84%

“…Fig. 2 below illustrates a conceptual model of requirements change implementation which was based on previous conceptual model work [19]. The conceptual model was updated with the empirical output from the focus group to produce the model.…”

Section: Methodsmentioning

confidence: 99%

“…Therefore, it is important to judge the affected and affecting elements accurately to ensure an adequate allocation of time and cost in implementing the change [33], [31]. Strategic planning and technology standards imposed by the organisation also have been found to influence the change implementation [19], [43].…”

Section: Related Workmentioning

confidence: 99%

“…The study uses a partial lease square structural equation modelling (SEM) technique. The identified risk factors discussed in this paper were acquired through series of work conducted previously, reported in [19].…”

Section: Introductionmentioning

confidence: 99%

See 3 more Smart Citations

Risk Factors for Software Requirements Change Implementation

Rahman

Razali

Ismail

2019

ijacsa

Self Cite

View full text Add to dashboard Cite

Requirements change has been regarded as a substantial risk in software development projects. The factors that contribute to the risk are identified through impact analysis, which later determine the planning of the change implementation. The analysis is however not straightforward as the risk factors that constitute requirements change implementation is currently not much explored. This paper identifies the risk factors by firstly collating them qualitatively through a review of related work and a focus group study. The factors are then confirmed quantitatively through a survey in which data is analysed by using Partial Least Squares Structural Equation Modelling (PLS-SEM). The survey comprise of 276 practitioners from software industry who are involved in the impact analysis. The results indicate that User, Project Team, Top Management, Third Party, Organisation, Identification of Change, Existing Product and Planning of Change Implementation are the significant risk factors in planning of requirements change implementation.

show abstract

Section: Methodsmentioning

confidence: 84%

Section: Methodsmentioning

confidence: 99%

Section: Related Workmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

See 2 more Smart Citations

Risk Factors for Software Requirements Change Implementation

Rahman

Razali

Ismail

2019

ijacsa

Self Cite

View full text Add to dashboard Cite

show abstract

“…Penilaian peringkat resiko khususnya melibatkan identifikasi resiko, analisis resiko dan penentuan prioritas resiko [19]. Hal ini sangat penting karena dapat menentukan penilaian resiko terhadap perubahan-perubahan yang akan terjadi [20]. Dampak resiko ini dilihat dari data RPO, RTO dan MTD yang telah dikumpulkan.…”

Section: Metode Penelitianunclassified

Perancangan Contingency Planning Disaster Recovery Unit Teknologi Informasi menggunakan NIST SP800-34

Prabowo¹,

Ramadhani²

2021

View full text Add to dashboard Cite

Pembangunan institusi pendidikan selama ini telah bertumbuh pesat sesuai dengan kebutuhan masyarakat dan menjadikan sebuah insitusi yang semakin komplek dengan kebutuhan fungsi operasional sistem layanan informasinya. Untuk menjalankan fungsinya, institusi pendidikan didukung oleh infrastruktur sistem layanan teknologi informasi yang sangat kompleks. Dalam penyelenggaraan fungsi operasional layanan tersebut, perguruan tinggi membutuhkan peran sistem teknologi informasi yang handal dalam keberlangsungan kegiatan kerjanya. Semua komponen teknologi informasi merupakan komponen yang rentan terhadap gangguan baik itu dari internal maupun eksternal, untuk itu dalam penyelenggaraan institusi pendidikan, perguruan tinggi dalam hal ini wajib memiliki rencana untuk menanggulangi segala gangguan maupun bencana. Dalam hal ini penanganan penanggulangan ganguan dan bencana memuat beberapa prosedur dan mekanisme tersendiri dalam pengamanan datanya. Disaster Recovery Plan (DRP) merupakan langkah tepat dalam membangun penanganan gangguan dan bencana terhadap infrastruktur sistem layanan teknologi informasi yang ada di perguruan tinggi. Penerapan untuk membangun penanganan bencana ini mengacu pada NIST SP 800-34 Rev.1 yang didalamnya terdapat beberapa tahapan penilaian resiko, menganalisa dampak bisnis, mengidentifikasi pencegahannya dan pengembangan strategi mitigasi. Hasil akhir dari penelitian ini adalah rancangan dokumen DRP berdasarkan NIST SP 800-34 Rev.1 yang disesuaikan dengan kondisi di perguruan tinggi

show abstract

A metric for quantifying the ripple effects among requirements

et al. 2022

View full text Add to dashboard Cite

During software maintenance, it is often costlier to identify and understand the artifacts that need to be changed, rather than to actually apply the change. In addition to identifying the artifacts related to the change per se, one needs also to identify the artifacts that are changed due to ripple effects. In this paper, we focus on ripple effects and propose a metric for assessing the probability of one requirement to be affected by a change in another requirement (i.e., requirements ripple effect). We focus on the requirements level, since most maintenance tickets (which stem from the customer) are captured in natural language and therefore are more naturally mapped to requirements, rather than source code. The proposed metric-the requirements ripple effect measure (R2EM)-is calculated by considering the conceptual overlap between the involved requirements (through their past co-change), the parts of the code in which they are implemented (i.e., their overlapping implementations), and the underlying dependencies of the source code (i.e., ripple effects between classes). We note that despite the involvement of source code artifacts in the calculation of R2EM, this metric is considered as a requirements' level one, since the unit of analysis is pairs of software requirements. To validate the proposed metric, we conducted an industrial case study, on two enterprise applications of an SME. The study design involved both quantitative and qualitative data, and input was given by 9 practitioners. The results suggested that R2EM is able to identify ripple effects between requirements at a satisfactory level, and those effects are mostly caused by overlapping implementations and source code ripple effects of these implementations.

show abstract

A Risk Model of Requirements Change Impact Analysis

Cited by 10 publications

References 23 publications

Risk Factors for Software Requirements Change Implementation

Risk Factors for Software Requirements Change Implementation

Perancangan Contingency Planning Disaster Recovery Unit Teknologi Informasi menggunakan NIST SP800-34

A metric for quantifying the ripple effects among requirements

Contact Info

Product

Resources

About