COMMUNICATION CHALLENGES IN REQUIREMENTS DEFINITION: A CLASSROOM SIMULATION

ATTENTION:

BEFORE YOU READ THE ABSTRACT OR CHAPTER ONE OF THE PROJECT TOPIC BELOW, PLEASE READ THE INFORMATION BELOW.THANK YOU!

INFORMATION:

YOU CAN GET THE COMPLETE PROJECT OF THE TOPIC BELOW. THE FULL PROJECT COSTS N5,000 ONLY. THE FULL INFORMATION ON HOW TO PAY AND GET THE COMPLETE PROJECT IS AT THE BOTTOM OF THIS PAGE. OR YOU CAN CALL: 08068231953, 08168759420

WHATSAPP US ON 08137701720

COMMUNICATION CHALLENGES IN REQUIREMENTS DEFINITION: A CLASSROOM SIMULATION

INTRODUCTION Systems analysis and design is a standard course offering within information systems programs and often an important lecture topic in Information Systems core courses. Given the persistent difficulty that organizations experience in implementing systems that meet their requirements, it is important to help students in these courses get a tangible sense of the challenges they will face, whether as Information Systems practitioners or business professionals, in the systems analysis and design process. This article presents a hands-on design game that focuses in particular on the structuring of opportunities for user participation in requirements definition. The game provides an opportunity to raise central questions about communication, knowledge transfer, and the level and timing of user involvement during systems projects. Students are organized into small groups that adopt multiple roles over the course of a simplified “system” development life cycle. Each group begins in the role of users with the initial articulation of a business need or opportunity, which they simulate by creating a model using Lego blocks. The Lego models are then put away, and pairs of teams exchange roles as users and analysts in conversations focused on preparing requirements documents that will give an account of each user team’s model. During the subsequent construction phase, programmer teams attempt to use these requirements documents to recreate the original models. Acceptance testing follows, during which the entire class evaluates pairs of models–in each case, the original model representing the users’ business requirements and the corresponding model created by the programmer team. The final step in the exercise is a post-project review, when the class discusses the challenges that arose during the game, and the instructor draws parallels to problems in system implementation practice. This exercise has been used and refined over a period of several years in core courses in information technology management at both the undergraduate and graduate levels and in classes in systems analysis and design. Students find the exercise highly engaging, and the divergent mismatches that always surface between “before” and “after” models are the cause of hilarity and good-natured finger-pointing. (See Figure 1a below with a “before” model on the left and the companion “after” model on the right; the requirements document is in Figure 1b.) [FIGURE 1A OMITTED] [FIGURE 1B OMITTED] The full payoff comes in the final phase, when students, with the instructor’s guidance, draw out parallels between the difficulties encountered first-hand in the interpersonal communication of the game and the problems that commonly arise in translating business professionals’ requirements via systems analysis for software builders. This also provides an opportunity to explore the implications of alternative project structures for user participation, and to make connections more broadly to issues of IT governance and business-side accountability. We begin our discussion here with some theoretical grounding in user participation issues, and we then explain how the Design Game helps to surface problems in this domain. After a summary overview of the game, step-by-step instructions are offered for conducting the exercise. Next, we provide detailed teaching notes to help guide instructors in preparing materials, integrating the exercise within a course plan, facilitating the related class discussion, and making the most of the game as a metaphor for real-world challenges in user participation. We conclude with some observations on learning outcomes, based on our experiences in using the game. 2. USER PARTICIPATION IN SOFTWARE DEVELOPMENT In the 1980s and 1990s system development methodologies relied upon the identification of known requirements (Valusek and Fryback, 1985) in a manner that didn’t accurately model the real world as users experienced it (Land, 1982).

HOW TO RECEIVE PROJECT MATERIAL(S)

After paying the appropriate amount (#5,000) into our bank Account below, send the following information to

08068231953 or 08168759420

(1) Your project topics

(2) Email Address

(3) Payment Name

(4) Teller Number

We will send your material(s) after we receive bank alert

BANK ACCOUNTS

Account Name: AMUTAH DANIEL CHUKWUDI

Account Number: 0046579864

Bank: GTBank.