You've just been hired by the CTO of Neo-Record Corp, who wishes to create a new distribution model for digital music.
"We want to be like the iTunes Store and Bit-Torrent combined, but provide financial incentives for individuals to distribute music. Crazy, huh!" He continues to describe the system:
"We want everyone to use our music catalog, which in one sense is a desktop application used to organize and play a music collection. You know, like iTunes! Except we call it OmniTunes, cool huh?"
"The thing is, OmniTunes doesn't just list the music owned by the user -- it literally is a catalog of every single piece of music ever recorded. The user can play any song in the catalog."
"When a user chooses to listen to a song, the application first tries to see if a recording is stored locally on the user's computer. If it isn't, the application tries to connect to other OmniTunes applications on the network. If another OmniTunes application has the digital file, the requesting OmniTunes application can play back the song."
"Ultimately, if the OmniTunes software can't find the file locally or on the network of other OmniTunes clients, it requests the song from a distribution server."
"Now you have to realize that any time an OmniTunes user tries to play a song and the application has to go out and get it, a monetary transaction has to take place. For example, I might be charged a nickel to play a song that is stored on my neighbor's OmniTunes application. That nickel would go directly into my neighbor's account. The transactions should be stored on each OmniTunes application as well as being stored on the Neo-Record Corp's OmniServer."
"I'll give you another example. Say the OmniTunes user ends up requesting the song from a distribution server, which is really just like an OmniTunes application except it has tons of digital music stored with it and is likely owned by a major record label. That record label might charge $2 to playback the song. However, once the user pays the fee, the user is free to distribute that song and charge money for it."
"Eventually, we'll have an entire economy of music on our hands, and everyone will be making money. Especially us here at Neo-Record Corp!"
"So what we need you to do is to build both the OmniTunes p2p applications and the server applications responsible for monitoring the network, storing transactions, etc. And we'll pay you a million bucks, how does that sound?"
"But first thing's first -- lets start with the OmniTunes application itself."
This is a typical, high level description of what management-types consider a specification. "Here's the wacky idea, it will kind of work like this, now can you build it?"
The assignment is to first design the database for the OmniTunes P2P client application.
Realize that the OmniTunes database will have to include some music catalog-like information, store playback data, etc. Information about other OmniTunes nodes on the network will be retrieved from a server, but stored locally as well.
Also, transaction information must be stored, such as where the song was retreived from, the cost, the date of the transaction, etc.
The first step in designing your database is figuring out exactly what you will be modeling.
In class, we reviewed the general design 'process' of problem definition, requirements gathering, scenario building, etc.
In your documentation, you must:
Documentation is often overlooked by development teams and project owners and is seldom read... who wants to read a dry, boring piece of documentation? And who enjoys writing dry and boring stuff? Make your documentation interesting and a worthwhile read by writing in your own voice, injecting humor into it, adding weird but meaningful sketches/diagrams, etc.
Don't get too caught up in trying to craft the perfect use cases / scenarios. Just tell a story; that's all a scenario is.
Don't be a slave to the diagram -- it doesn't have to be perfect, and will inevitably change. If something in the diagram begins to feel too complex, don't hesitate to 'cheat' with sentences on the side, additional arrows explaining things, etc.
Hand your system documentation to a non-technical friend, and offer them a beer if they'll read it. If they can't understand it, either your documentation needs to be refined or your friend drank too much.
Spend time thinking about the data model. Ask questions via email, I will distribute the answers online. We will have a short q/a requirements session on Monday, Jan 28 in class.