What do game designers do? They make the blueprints, termed design documents, that describe the nature of the software that the rest of the team will build. Writing and maintaining this documentation is itself a full-time job in most large projects. It's necessary; a game without a designer is likely to be difficult to use and not much fun.
These same tasks are useful for any large software project, not just games. So where are all the "game designers" in the greater software industry?
These people do exist, but it's hard to find them. Not all companies have them; some companies still operate under the antiquated assumption that anyone who can program in Java is fully qualified to design the software architecture. The companies that do have "designers" call them many different names. Microsoft calls them program managers. Other places call them system analysts. Some companies with highly technical systems require their "designers" to write some code, so they call them programmer/analysts. Still other places hire from outside, and they're simply called consultants. For my purposes, I think system analyst is the most descriptive, so I'll conveniently go with that term.
And so it comes to pass that I find myself teaching a course called Systems Analysis. While it has nothing overtly to do with the game industry, the topics overlap with game design a great deal. We talk about the iterative method of development, rapid prototyping, user interfaces, focus groups and research into the subject area of the software. It's the same thing, except with all the fun apparently sucked out of it.
And this, ironically, is why I'm so excited about teaching the class. It lets me put into practice everything that I've been preaching about using game-like techniques to teach a non-game class, and the evils of multiple choice. If I can take this class and make it fun, it validates everything I've been doing as a game-designer-turned-teacher. And if not... well, I can always go back to my game classes with their inherently fun content.