Analysis of Requirement Problems regarding their Causes and E ects for Pro jects with the ob jective to Model Qualitative PRIs - Empirical Study

Abstract

[Context and motivation] It becomes increasingly di cult to implement and establish a qualitative requirements engineering (RE) continuously in end-to-end system. Missing stakeholder analysis and miscasts within the project management (PM) are additional reasons for a poor causal chain in projects. [Question/problem] Scienti c papers (P1) were collected from earlier journals/magazines and conferences to understand the statements and allegations of two prominent sources (The Standish Group (1995) and Rogers (2016)) The content examination is carried out in the form of aka Causes and E ects (C&E) diagram, the Ishikawa-diagram. [Principal ideas/results] With the help of the results obtained from both sources and the P1, perfectly tailored requirements - Product Requirements Information (PRI) - are made available to all stakeholders in a requirements catalog. With the help of a project (Pilot1), unspeci ed requirements from industrial operators are additionally used as further input in order to model PRI. [Contribution] The purpose of this paper is to deliver solutions, procedure models regarding the two prominent sources to model the future PRIs.

Keywords

• Requirements Engineering
• Requirements Modeling
• Requirements Catalog
• Product Requirements Information
• Enterprises
• Project Management
• Ishikawa Diagram

-

identi es the eight requirement problems in projects. Rogers (2016) is mentioning also the concerns from The Standish Group (1995), [ 10 ] which is analyzing the reasons for the failure of IT-projects in enterprises since 1984. These sources [ 7 ] and [ 10 ] provide the foundation for this work. The objective of this paper is to examine the reasons and causes for the failure of IT-projects in enterprises, with the help of those two sources. The available results from both sources, perfectly modeled requirements, called Product Requirements Information (PRI), will be provided as a requirement catalog for all stakeholders in an end-to-end system. Stakeholders should be relieved of the pressure by forwarding the PRI to developers and manufacturers. The development of the end-to-end system will take place in further papers and is not part of this paper. Figure 1 provides a guide to the orientation of the entire paper, which is referred in the following sections. The paper is organized as follows: Section II covers the research preview with the following sub-section: Research Question (RQ1) and the three hypotheses (H1-H3) from previous journals/magazines and conferences with their implementation into the Ishikawa Methods Overview as well as the individual steps for the design of the PRI. Section III describes the current progress description and the problem. A discussion is given in section IV of the available results and conclusion. 2

Research Preview

With the help of research results from Rogers (2016) and The Standish Group (1995), solutions for a perfect Product Requirements Information (PRI) are to be provided. Both sources point to unspeci ed requirements, but do not address or deliver solutions. With the help of collected scienti c papers (P1) within the last 10 years from journals/magazines and conferences, the mentioned problems of the two sources are analyzed and examined in detail to create solutions. 2.1

Scienti c Papers (P1)

Literature Review: Gareth Rogers (2016) [ 7 ] has identi ed the eight most frequently discussed requirement problems of projects with the help of a literature research. These are: 1) Missing requirements, 2) Hidden stakeholder needs, 3) Inadequate or ambiguous requirements, 4) Con icting requirements, 5) Lack of measurability or testability of requirements, 6) Onward communication of requirements, 7) Changing requirements and 8) Over-speci ed requirements. The scienti c paper (P1) based on Rogers (2016) requirement problems. The P1 were published in journals/magazines and conferences. The objective of this literature review regarding Rogers (2016) requirement problems, is analyzing and nding solutions with the help of the collected P1. With the delivered help of the solutions, there will be modeled the future PRIs. 2.2

Project - Pilot1

Empirical Study: The Pilot1 project has to be seen isolated from P1 and the two prominent sources. Since the P1s do not include any requirements but are rather an evidence of the forwarded way for the PRI, there has been contacted and interviewed four industrial manufacturers: wholesale and retail, healthcare, IT-companies and automotive manufacturers. These selected industrialists were taken from The Standish Group Report [ 10 ] and [ 4 ]. Although most of the responsible Industrial contact person was primarily interested in business bene ts rather than science measures they keep asking about the investigative results [ 9 ]. This study was designed with an explorative search (qualitative content analysis). All the 30.000 delivered unspeci ed/anonymous functional and nonfunctional test requirements (Pilot1) are stored in a MySQL DB. See (ps4 in gure 1) and provide a template for modeling the future PRIs. The aim of Pilot1 is to gather insights how to create perfectly modeled requirements for stakeholders from these unspeci ed requirements using the individual requirements stencil (ps7 in gure 1) and the SRS standard (ps9 in gure 1) to model the future PRIs. Using the solutions from the P1 as literature review, the rst research question (RQ1) followed by three hypotheses (H1-H3) should be investigated and answered: 2.3

Research Question

{ RQ1: What solutions help to implement requirement models in Enterprises? H1: The problems mentioned by Rogers (2016) and The Standish Group (1995) are known to stakeholders but were ignored for di erent reasons H2: The ndings from P1 provide matching solutions, procedural models and RE processes to Rogers (2016) eight requirement problems

H3: Pilot1 project will help to model the future PRIs The RQ1 was modeled regarding the two sources. There are some results on the three hypotheses due to temporary investigations, which, however, can not be considered as absolute. In answering the RQ1, P1 will provide answers in form of an empirical literature review from the earlier journals/magazines and conferences. Parallel to P1, the unspeci ed/anonymous functional and non-functional test requirements from the industrialists (Pilot1) are examined. In order to connect with the reality, the author's experience as a requirements engineer from ITprojects will be integrated into this work. With the help of the practical reference and the scienti c elaborations in combination, the problem of all stakeholders can be referred to this modus operandi.

For further analysis of the P1, these P1 passes through an Ishikawa Methodology Overview [ 3 ] (ps5 in gure 1). Unfortunately, there is no space to discuss the details of this Ishikawa Methodology Overview in detail. With the implementation of Kaizen tools like Ishikawa, there will be approach process versus result, putting quality rst and speaking with data. Kaizen provides companies committed to pollution prevention with a way to focus on enterprise solutions while moving away from concepts of radical innovation [ 8 ] and looks at the top and middle management and supervisor and worker [ 5 ] activities. The methodology is taken from ISO / IEC 12207 (Systems and Software Engineering) under the heading Total Quality Management (TQM) as an orientation for agile projects. This standard implements the principles of quality management. The Ishikawa-diagram also named as Causes and E ects diagram, (C&E) diagram, starts with the core question or a core problem, that divides the causes into di erent areas in the root cause research, which are then further investigated [ 6 ]. The C&E diagram is divided into 2 columns: the cause and e ect columns, where the e ect refers to the causes of the faulty requirements. All eight of Rogers's (2016) requirement problems were numbered in the C&E diagram. This procedure di ers from the original C&E diagram as follows: The main inuencing variables in the C&E diagram relate to the 8M (material, machine, method, human, management, milieu, measurement and money). However, as the P1 focuses on the main focus of Rogers (2016) eight requirement issues, the original 8M has been replaced by Roger's (2016) requirement problems. For a better understanding, a suitable P1 for the problem: Missing Requirements ( gure 2) were inserted and examined according to the criteria of the C&E diagram. For this purpose, ve causes were analyzed (1.1-1.5) and identi ed on the horizontal arrows, which represent the initial situation at its peak as a possible cause (causative cause). In the next step, the main in uencing variables, if there are any, the secondary in uence variables will be added (see in gure 2 the slanted arrows). Previously, other methods were used such as the 5-W question model and failure mode and e ects analysis (FMEA). The Ishikawa-diagram was selected for the following reasons: Checking for completeness and promoting a better understanding of problems and their causes, the C&E user can de ne the intensity of the cause depth on the basis of existing requirements and display them graphically simply. The veri cation of the worked out causes and their correctness in the respective P1 was determined with the help of the following questions: { What is the research goal of the author? { What causes/triggers the requirement problems which were identi ed by the author? { What conclusion does the author reach? All collected P1s previously undergo an Ishikawa Methodology Overview (ps5 in gure 1), which is divided into two gates: Feasibility and Case Study. If a P1 does not pass through the gate feasibility study because it does not provide the desired conditions from Rogers (2016) requirement problems, then it is sorted out. When the gate case study is passed, the P1 is sorted into the Ishikawa Causes and E ects C&E diagram. Based on the already studied P1 according to Roger's eight requirement problems (see gure 2), it turns out that other important keywords are mentioned by the P1 authors. For this reason, the scope of the following keywords in a second C&E diagram must be expanded. The additional keywords are: Customer, design, input, internal/external development methods, internal/external projects, internal/external RE processes, methods, product, project and organization, RE processes, stakeholders, system, tools, validation and veri cation. These keywords are based, among others, on the projects of Mendez [ 1 ] and Hall et al. [ 2 ]. In summary, this means that in the rst C&E diagram (see gure 2), all P1s are roughly sorted according to Roger's requirement problems, and then a granular extended search follows with the help of the second C&E diagram. The search results of all keywords in the second C&E diagram are displayed in percentage format for a better weighting orientation within the solution analysis. 2.4

PRI Design

All 10 process sequences (ps1-ps10), in gure 1, represent the entire design of the PRI. With the Ishikawa Methodology Overview (ps5), all collected P1 (ps2) in the Ishikawa-diagram are extensively studied and analyzed. In parallel, the elicited Pilot1 (ps3) are stored in the MySQL DB (ps4). All Pilot1 are modeled using an updated individual requirements stencil (ps7). This means that from these unspeci ed requirements, which are one of the main causes of misunderstandings between stakeholders and developers, are processed grammatically in such a way, that all linguistic conditions are correctly formulated. All existing results from (ps1) to (ps7) are merged and subjected to re-analyze again (ps8). With the IEEE Standard 830-1999 (ps9), all requirements according to the Software Requirements Speci ed (SRS) veri cation standard are to be subjected. This standard is the nal step for designing of all PRI. 3

Progress Description

The P1, which does not pass through the rst gate of the Feasibility Study within the Ishikawa Methodology Overview, are sorted out. Possibly these can be considered as re-use requirements for further investigations. The Pilot1 obtained from the four industrialist sectors are sorted according to a prede ned MySQL DB table with the aim of modeling uniform column names. These column names then serve as inputs to an end-to-end system, in which all PRI are made available to stakeholders in form of a requirement catalog. 3.1

Research Problem

Many P1 authors name their research goal with research questions and hypotheses, but the path to problem-solving is nontransparent. Therefore it is di cult to sort the P1 after the two gates within the Ishikawa Methodology Overview. Extensive procedures for applied and investigated methods as well as procedural models are described. Due to a lack of retrospective, research questions and hypotheses are hardly comprehensible. In most of the P1 conclusion, the authors are describing vehement research problems that were not foreseen in the course of the research work and they raise up their research targets to be discussed. After examination of all given P1 paper, there should be used further keywords (these additional keywords were named at the end of the chapter 2.3 research question) similar to Rogers (2016) problems.The DB-Design is still in test phase because of the Pilot1 from the di erent industrialist sectors has serious divergences by the DB column names. 4

Discussion and Conclusion

According to the present investigations so far, the RQ1 with the three hypothesis cannot be answered yet. From the obtained results, however, the following new approaches emerge as a temporary solution from the analyzed P1, which must be considered critically: Literature Review: P1 - In order to relieve internal stakeholders, external stakeholders are purchased to create requirements. The problem is, that the external stakeholders were not involved in the project right from the start. Added to this problems are such as language barriers between internal and external stakeholders. This causes a temporal increase in the transmission of the requirements to the developers and manufacturers. Because of this problems, project deadlines could not meet their deadlines. Communication barriers between stakeholders could be further problems, which should be added to Rogers (2016) eight requirement problems. P1 authors often use a special approach by stakeholders, which corresponds to a reverse engineering procedure. Due to time pressure or budget de cit, requirements are not written until the system has been developed and built. At this point, reverse engineering, was neither addressed by The Standish Group (1995) nor by Rogers (2016). The extent to which reverse engineering in enterprises is used by stakeholders is examined in further studies and theories according to their validity.

Empirical Study: Pilot1 - The rst 600 unspeci ed/anonymous functional and non-functional test requirements were read and have currently a lack of internal coherence. Here is an example: 1) The SystemX must be able to pass data to the SystemY, which must be analyzed by SystemZ. 2) The SystemX with the following properties A, B, and C must pass to the SystemY login data which may contain only the properties A) and C). Because of strong anonymization of the properties of the system, a meaningful reference to the individual tasks and executions of the system is not possible.

References

1. Fernandez , D Mendez and Wagner, Stefan and Kalinowski, Marcos and Felderer, Michael and Mafra, Priscilla and Vetro, Antonio and Conte, Tayana and Christiansson, M-T and Greer, Desmond and Lassenius, Casper and others: Naming the pain in requirements engineering . Empirical software engineering 22(5) , 2298 { 2338 ( 2017 )

2. Hall, Tracy and Beecham, Sarah and Rainer, Austen: Requirements problems in twelve software companies: an empirical analysis . IEE Proceedings-Software 149 , 153 { 160 ( 2002 )

3. Kato , I. and Smalley , A. : Toyota Kaizen Methods: Six Steps to Improvement . Taylor & Francis ( 2010 )

4. Lynch , Jennifer: Standish Group 2015 CHAOS Report- Q&A with Jennifer Lynch. Retrieved 1 ( 15 ), 2016 ( 2015 )

5. Masaaki Imai : Gemba Kaizen: A Commonsense Approach to a Continuous Improvement Strategy 2/E . McGraw-Hill Professional ( 2012 )

6. Medinilla , A. : Agile Kaizen: Managing Continous Improvement Far Beyond Retrospectives . Springer Berlin Heidelberg, 1 edn . ( 2014 )

7. Rogers , Gareth: RE in Agile Projects: Survey Results: Results of Research Project Announced in a Previous Issue . ( 2016 )

8. Soltero , Conrad and Waldrip, Gregory: Using kaizen to reduce waste and prevent pollution . Environmental Quality Management ( 2002 )

9. Sommerville , Ian and Ransom, Jane: An empirical study of industrial requirements engineering process assessment and improvement . ACM Transactions on Software Engineering and Methodology (TOSEM) ( 2005 )

10. Standish , Group: The CHAOS Report . The Standish Group ( 1995 )