---

LBSC 796/INFM 718R
Information Retrieval Systems
Spring 2011
System Design

Before you can build a system, you need to envision it. It will help you a lot to write this down, because while it lives only in your mind it is hard to know what you have not yet decided on. Writing it down will also help you to determine later whether you accomplished what you set out to do, but that is not the main point (since we can reasonably hope that you'll learn something along the way!). If you are already familiar with some formalism for creating functional specifications or parts of functional specification (e.g., UML) it is fine to use what you're comfortable with. If not, the following way of thinking though the process should be helpful.

You can think of a functional design as having three parts:

• 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 them.
  • 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 many modes, among which are 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 the slides from week 1 to get a feel for what some 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 two 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 really want to search the live Web, but for simplicity you might instead just use a canned set of Web pages that someone else has put together for you.
  Note that although you need to think in some detail about the basis for your choices, when it comes to writing about scope all you need to do is describe which parts of your vision you actually do 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 design process, because the resulting 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 as a 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.