=Paper=
{{Paper
|id=Vol-2075/DS-paper3
|storemode=property
|title=Analysis of Requirement Problems Regarding their Causes and Effects for Projects with the Objective to Model Qualitative PRIs - Empirical Study
|pdfUrl=https://ceur-ws.org/Vol-2075/DS-paper3.pdf
|volume=Vol-2075
|authors=Serda Hauser
|dblpUrl=https://dblp.org/rec/conf/refsq/Hauser18
}}
==Analysis of Requirement Problems Regarding their Causes and Effects for Projects with the Objective to Model Qualitative PRIs - Empirical Study==
https://ceur-ws.org/Vol-2075/DS-paper3.pdf
Analysis of Requirement Problems
regarding their Causes and Effects for Projects
with the objective to Model Qualitative PRIs -
Empirical Study
Serda Hauser
University Leipzig, Faculty of Economics and Management Science,
Information Systems Institute,
Chair Application Sytems in Business and Administration
Grimmaische Strasse 12, 04109 Leipzig, Germany
serda.hauser@gmail.com
https://iwi.wifa.uni-leipzig.de
Abstract. [Context and motivation] It becomes increasingly diffi-
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 rea-
sons for a poor causal chain in projects. [Question/problem] Scientific
papers (P1) were collected from earlier journals/magazines and confer-
ences 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 Effects (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), unspecified requirements from industrial op-
erators are additionally used as further input in order to model PRI.
[Contribution] The purpose of this paper is to deliver solutions, pro-
cedure models regarding the two prominent sources to model the future
PRIs.
Keywords: Requirements Engineering, Requirements Modeling, Require-
ments Catalog, Product Requirements Information, Enterprises,
Project Management, Ishikawa Diagram.
1 Introduction
A literature research by Rogers (2016) [7] in the Requirements Engineering mag-
azine (RE), based on the International Requirements Engineering Board (IREB),
Copyright 2018 for this paper by its authors. Copying permitted for private and
academic purposes, position footnote.
identifies the eight requirement problems in projects. Rogers (2016) is mention-
ing 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, per-
fectly 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:
Fig. 1. Overview of all process sequences for PRI modeling
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 unspecified requirements, but do not address
or deliver solutions. With the help of collected scientific 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 Scientific Papers (P1)
Literature Review: Gareth Rogers (2016) [7] has identified the eight most fre-
quently 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) Conflicting requirements, 5) Lack of
measurability or testability of requirements, 6) Onward communication of re-
quirements, 7) Changing requirements and 8) Over-specified requirements. The
scientific 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 finding
solutions with the help of the collected P1. With the delivered help of the solu-
tions, 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 re-
sponsible Industrial contact person was primarily interested in business benefits
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 unspecified/anonymous functional and non-
functional test requirements (Pilot1) are stored in a MySQL DB. See (ps4 in fig-
ure 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 unspecified requirements using the individual requirements stencil
(ps7 in figure 1) and the SRS standard (ps9 in figure 1) to model the future
PRIs. Using the solutions from the P1 as literature review, the first 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 different reasons
• H2: The findings 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 confer-
ences. Parallel to P1, the unspecified/anonymous functional and non-functional
test requirements from the industrialists (Pilot1) are examined. In order to con-
nect with the reality, the author’s experience as a requirements engineer from IT-
projects will be integrated into this work. With the help of the practical reference
and the scientific 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 Method-
ology Overview [3] (ps5 in figure 1). Unfortunately, there is no space to discuss
the details of this Ishikawa Methodology Overview in detail. With the implemen-
tation of Kaizen tools like Ishikawa, there will be approach process versus result,
putting quality first and speaking with data. Kaizen provides companies com-
mitted 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 Effects diagram, (C&E) dia-
gram, starts with the core question or a core problem, that divides the causes
into different areas in the root cause research, which are then further inves-
tigated [6]. The C&E diagram is divided into 2 columns: the cause and effect
columns, where the effect 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 differs from the original C&E diagram as follows: The main in-
fluencing 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
(figure 2) were inserted and examined according to the criteria of the C&E di-
agram. For this purpose, five causes were analyzed (1.1-1.5) and identified on
the horizontal arrows, which represent the initial situation at its peak as a pos-
sible cause (causative cause). In the next step, the main influencing variables, if
there are any, the secondary influence variables will be added (see in figure 2 the
slanted arrows). Previously, other methods were used such as the 5-W question
model and failure mode and effects 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 define the
intensity of the cause depth on the basis of existing requirements and display
them graphically simply. The verification 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 identified by the
author?
– What conclusion does the author reach?
Fig. 2. Rogers vs Ishikawa
All collected P1s previously undergo an Ishikawa Methodology Overview (ps5
in figure 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 Effects C&E diagram. Based on the already studied P1 according
to Roger’s eight requirement problems (see figure 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 verification. These keywords are based, among others, on the
projects of Mendez [1] and Hall et al. [2]. In summary, this means that in the
first C&E diagram (see figure 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 figure 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 unspecified requirements, which are one of the main causes of misunder-
standings 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 Soft-
ware Requirements Specified (SRS) verification standard are to be subjected.
This standard is the final step for designing of all PRI.
3 Progress Description
The P1, which does not pass through the first 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 predefined 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 hypothe-
ses, but the path to problem-solving is nontransparent. Therefore it is difficult
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 hy-
potheses 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 different 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 ex-
ternal 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 require-
ments to the developers and manufacturers. Because of this problems, project
deadlines could not meet their deadlines. Communication barriers between stake-
holders 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 deficit, requirements are not written until the system has been devel-
oped and built. At this point, reverse engineering, was neither addressed by The
Standish Group (1995) nor by Rogers (2016). The extent to which reverse engi-
neering in enterprises is used by stakeholders is examined in further studies and
theories according to their validity.
Empirical Study: Pilot1 - The first 600 unspecified/anonymous functional
and non-functional test requirements were read and have currently a lack of in-
ternal 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. Fernández, D Méndez and Wagner, Stefan and Kalinowski, Marcos and Felderer,
Michael and Mafra, Priscilla and Vetrò, Antonio and Conte, Tayana and Chris-
tiansson, 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 Im-
provement Strategy 2/E. McGraw-Hill Professional (2012)
6. Medinilla, À.: Agile Kaizen: Managing Continous Improvement Far Beyond Ret-
rospectives. 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)