LIS 7610/CSC 7481 Project Part 1: System Design

Last update: August 16 2012.

• Goal: The problem to be solved. Don't overdo this part -- if you can't explain your goal in a single paragraph, you probably don't understand it well enough yet. There are two key elements here:
  • Who is your user? Don't try to solve all problems for all people. Pick someone whose needs you want to meet, and build your system for him/her.

  • What do you want to help your user do? You can and should mention what collection your user will be searching, but you should go beyond that to think through what they are trying to do with that collection.

• Product: What you plan to deliver. Here the key is to imagine how your system will be used, and then to progressively refine your understanding to ultimately articulate how it will work. You probably won't need more than a page of text to do this well, but you may (and probably will) need several additional pages of figures to capture what you need to say about this. There are two key pieces here:
  • What the user can do. This is most often articulated by starting with a use case, which in its simplest form is just a story about a very concrete instance of using your system. From there, it is often useful to sketch out what the screen will look like, often with more than one sketch if your system has different "modes" (for example, Google has three modes -- simple query, advanced query, and result display). Sketches of static screens, coupled with the words you write about them, may be enough to capture the key ideas. If not, then you might also want to include a "process diagram" that shows how the user gets from one screen to another (any easy way to think of this is that the screens become small labeled boxes in a process diagram, and the arrows between those boxes represent user and system actions).

  • What the system will do. Up until now you have been thinking like a "user experience designer". Now it is time to start thinking like a "system designer". This does not mean thinking like a programmer -- we don't need pseudo-code, entity-relationship diagrams, or a data dictionary. But we do need some kind of idea where the system is going to get the information it needs to do its job and what it is going to do with it. This can often usefully sketched out as a "data flow diagram". Look back at slides from week 1 to get a feel for what data flow diagrams look like. Don't copy those, though -- just use the idea as a way of organizing your thoughts about what the system will do in a way that makes it possible to draw a useful diagram or two that you can talk about with words.

• Scope: What you do and don't plan to deliver. Up until now you have been writing about what is needed so solve the problem that you have chosen to work on. But you'll need to make some choices about which parts you're really going to build if you're going to have any hope of finishing before the end of the semester! There are three key factors to consider here:
  • Your team. How many people do you have, what do they already know how to do, and what do they want to learn how to do? Don't overlook that last point when you make your choices--shape your project to focus on what you most want to learn about!

  • Coherence. With limited time, you could either do a few things well (and fake the rest) or you could try to do many things but do none of them well. The right way to go here should be pretty clear -- pick some key parts of the problem to focus on. In order to do this, you'll need to know which parts you can "fake" (which, in polite company, is called "simulate"). For example, you might want to search the entire Web the Web, but for simplicity you might use a set of Web pages that someone else has put together for you.

  Note that you don't need to write about those factors -- rather, those factors should guide what you write about scope. Just describe which parts of your vision you actually plan to focus on and which you plan to simulate. Don't worry too much about this part -- if things go well, you can always do more (and if things turn out to be more complex than you had imagined, you'll already have some experience with making these kinds of choices). So don't spend more than a half page on this. Indeed, a few bullet points may be all that you really need. Students often observe, correctly, that they don't yet know enough to make the right choices about how much of the problem to tackle. One good rule of thumb for this is that you can probably do about half what you first think might be possible (because it is easier to see opportunities than obstacles when you are first starting out). Obviously that can be taken to extremes (particularly if you are a pessimist!), but the key here is just to make an initial guess of how much you can do, and then shape your choices about what to do to make the most of your time and effort.

Doing this kind of a design well requires that you stay out of the weeds and work at a level where you can see the big picture. Details can be seductive, and if you let them draw you down to too low a level you run the risk of designing the wrong thing well. Better to design the right thing incompletely. You'll get to the details soon enough -- the entire implementation process is essentially progressive refinement of your design.

It is important that your whole team contribute to this process, because this shared vision is one of the key things that will hold you together as a team. But it is not important that the document be written by the group. Indeed, it is probably best if one person takes the lead on pulling together the document, with several others contributing pieces and with everyone commenting and critiquing. Naturally, that process will go best if you don't leave it till the last minute.

The document you submit (by posting it on your Web page) will be read and returned with comments and with a grade. Don't read too much into the grade, though -- all I can hope to grade at this point is whether you addressed the things I asked you to (I will not be grading your drawing skills!). But the most important impact of this part of your project will be the role it plays in helping you to focus your efforts.