During the requirements analysis phase of information systems development, the user and analyst attempt to come to an agreement on the purpose of the system and the needs of the future users. When completed effectively, this process leads to the creation of an information system that fulfills the intended purpose and meets the needs of users and their organization, on time and within budget [3]. This, of course, is dependent on the successful completion of the rest of the development process including the designing, coding, and testing of the system. Problems unsolved in the requirements elicitation phase may worsen during the remainder of the systems development project. As over 50% of the errors in systems design and development are a result of inaccurate requirements, it is imperative this phase be completed accurately [6]. Often, information systems are designed and created that do not meet the needs of the users or fulfill their intended purpose [3, 6]. The deficiencies of these systems are often the result of problems such as miscommunication between the users and the analysts, poor elicitation of requirements, poor conversion of requirements to designs, and poor analysis or analyst technique [3, 5]. The last category, poor analysis or analyst technique, can be further broken down into a lack of training of data processing professionals [11]; poor user understanding of data models due to their design [4]; and poor or error-prone communication between the user and analyst [2, 10]. Specifically, the data flow diagram (DFD) created by the analyst toward the end of the requirements analysis phase can reflect many of these problems, and often reflects an incorrect system. Any research that successfully elicits factors that can be controlled and then used to improve this process is valuable to the entire systems development industry. An Experiment Attempts have been made to modify the process of creating data flow diagrams in an effort to increase their clarity, level of comprehension, learnability, and usability [7, 8, 9]. While the results have been fairly positive, the problems mentioned previously still
[1]
David C. Hay,et al.
Making Data Models Readable
,
1998,
Inf. Syst. Manag..
[2]
Patricia J. Guinan,et al.
Enabling Software Development Team Performance During Requirements Definition: A Behavioral Versus Technical Approach
,
1998,
Inf. Syst. Res..
[3]
Mary Sumner,et al.
Are structured methods for systems analysis and design being used
,
1986
.
[4]
Karen Holtzblatt,et al.
Requirements gathering: the human factor
,
1995,
CACM.
[5]
David John Jankowski,et al.
A cognitive information processing and information theory approach to diagram clarity: A synthesis and experimental investigation
,
1999,
J. Syst. Softw..
[6]
Iris Vessey,et al.
Requirements specification: learning object, process, and data methodologies
,
1994,
CACM.
[7]
Robert W. Zmud,et al.
A Synthesis of Research on Requirements Analysis and Knowledge Acquisition Techniques
,
1992,
MIS Q..
[8]
John T. Nosek,et al.
User Validation of Information System Requirements: Some Empirical Results
,
1988,
IEEE Trans. Software Eng..
[9]
Ido Millet,et al.
A proposal to simplify data flow
,
2009
.
[10]
Deepak Khazanchi,et al.
A new approach to problem definition : using information objects
,
1995
.
[11]
Ritu Agarwal,et al.
Cognitive Fit in Requirements Modeling: A Study of Object and Process Methodologies
,
1996,
J. Manag. Inf. Syst..
[12]
Gail Salaway,et al.
An Organizational Learning Approach to Information Systems Development
,
1987,
MIS Q..