Reading Response for Lecture 03

Below is a list of the readings for this class with some suggestions on how to approach them and questions for discussion in class. Please create a post in this discussion consisting of at least 200 words discussing any issue from the required reading for the week (you do not need to address one of the discussion questions below, but you are welcome to do so).  See the Reading Response Grading Rubric for details about how posts will be graded.

The Readings

Alistair Cockburn on Use Cases (Chapter 1 and Chapter 2 in online reserves). Alistair Cockburn wrote the book on use cases and this is the opening pages from that book. This reading is worth your close attention. In it, Cockburn explains what a use case is and why they are so valuable. He also identifies some of the factors you need to consider when writing a use case and gives some detailed examples of what a use case looks like. The one thing you should skip is section 2.3 on the last page of the reading.

Discussion questions: What is a use case? How will writing use cases help you create a better system for your client? How will it help you to design your system?

Technostress (link). This is a research paper on the phenomenon of technostress: how information technologies can actually increase stress for those who use them. This is a relevant topic for us in that as system designers we would like to create systems that minimize negative consequences like technostress while maximizing positive consequences like improved organizational performance. The challenge in reading this paper is that it is written for an academic audience and devotes considerable space to a discussion of the research literature and research methods. As practitioners, our goal is to extract the value from this paper without getting snowed under by the academic baggage that is less relevant for us. That said, we should be cautious in adopting or citing conclusions of papers without digging far enough in to the research to evaluate the rigor of the findings. For now, however, please focus on the following parts of the paper:

• the introductory material in which technostress is defined
• the description of the characteristics which affect technology adoption and technostress (beginning on p. 839 in the article)
• the results (beginning on p. 844). feel free to skip the stats details
• and especially: the implications for practice starting on p. 852

Discussion questions: How big an issue do you think technostress is for today's digital workforce? as system designers, what can we do to address this issue?

Excerpt from Zen and the Art of Motorcycle Maintenance by Robert Pirsig (online reserves). This reading is from a novel that chronicles a motorcycle trip in which the narrator comes to terms with several parts of himself and explores some fundamental philosophical questions. The focus of this book is seemingly quite far away from MI258 but we will find some very useful connections here. Start reading with the second full paragraph on page 66 of the book (the fifth page of the pdf file), which begins "To do this, first of all, a dichotomy is necessary," Look for the example a bit further on about how a motorcycle can be described in terms of its parts and functions. This is surprisingly similar to how information systems are described by systems analysts. Below are some discussion questions to help you figure out why you are reading this and how to read it. You don't have to really understand the cast of characters mentioned, but in case you are interested: Phaedrus refers to the narrator himself before he had shock therapy for mental illness (yes, it is a rather strange story). Chris is the narrator's son. John and Sylvia are friends of the narrator who are going on this trip. As an aside they are very much in the "romantic" camp, to use Phaedrus's terms. The book is from the 1970s and you might notice this shows in the assumptions made about men v. women.

Discussion questions: Systems analysis is typically experienced as a pure classical exercise (in the author's terms). The author talks about the limits of the classical view. Are these issues for systems analysis? How might we address them? Is there a place for the romantic perspective in systems design? Where does it show up? Do we need it? How do we make room for it?

Larman pp. 61-93, 493-500 (Chapter 6 through 6.19 and Chapter 30). This material from the Larman textbook covers use cases in detail and is meant to build on the big picture view you obtain from reading Cockburn (described above). You will be referring to this material as you start to actually write use cases and draw use case diagrams. In preparation for the class I recommend you skim this material and read only enough to answer the following questions:

• what is a use case diagram? how do you draw one? what value does the diagram add to the written use cases?
• what additional issues does Larman introduce that were not discussed in the Cockburn reading? when might these be useful? For now it is enough to just identify the issues; you do not need to absorb the detailed discussion.

The reason I am encouraging you to skim this material for now and to revisit it later is that the detailed discussion of use cases becomes much more meaningful and much more useful after you have started to write use cases for your own project.