Reading Response for Lecture 04

The readings this week focus on requirements gathering. How do we gather requirements from users and other organizational stakeholders? What documents and other "design artifacts" should we use to keep track of these requirements?

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

Gerald Weinberg on Observation and Interviewing (online reserves). These are relatively short, hopefully entertaining readings aimed at practicing systems analysts. The focus here is: the importance of looking at how things are now in a way that is useful (and avoids the "railroad paradox") and the importance of interacting with your clients/users in a way that leads to productive and informative conversations.

Discussion questions: Have you encountered any examples of the problems Weinberg describes or the techniqus he proposed? How might Weinberg's suggestions influence your plans to learn about your client's needs and existing systems?

Edgar Schein "The Corporate Culture Survival Guide" (online reserves).  Schein's notion of culture should make more sense after reading Weinberg: Weinberg points out that it is not always obvious why people do what they do and it is not always easy to communicate effectively with users in part because you have different assumptions. Culture is a way to capture some of this difficult to get at knowledge. Schein explains culture by identifying several distinct levels of culture and the proposes an approach for increasing your understanding of an organization's culture.

Discussion questions: What are the potential pitfalls of trying to deveop a system without understanding the organizational culture. Is it realistic for your team's project to do a 4 hour cultural assessment as Schein suggests? Is there a "lighterweight" alternative? What are the trade-offs?

Larman pp. 101-120 (Chapter 7). It turns out that use cases and UML diagrams are not by themselves enough to capture all the system requirements. There needs to be a way to capture the overall vision and functionality of the system and also requirements that do not fit into any one use case or any one diagram. In this chapter Larman describes a set of additional "requirement artifacts" (documents, mainly) which are used to capture these additional aspects of the design: supplementary specification, vision, business rules, and glossary. In your first reading of this material, do not focus on the detailed structure of these documents but rather what role each plays.

Discussion questions: Why would a design team choose to create and maintain these documents? Are there any you might omit or condense for your team's project, given its size and scope?