-
Notifications
You must be signed in to change notification settings - Fork 4
Inception
Vision Statement
The vision statement, also known as a project charter, should include an elevator summary of the project, a business case for the project (including a short analysis of the competition, market space, or similar commercial off the shelf software), a description of the project stakeholders, a list of the major features of the completed project, and a list of the major risks of the project.
Elevator Summary:
Our project is an add-on for the music player Songbird. We are creating a recommendation engine to better choose which songs the user wants to hear. It will be different from other recommendation engines because it will record and use the time at which a song was played, rated, skipped or selected. This will allow it to play songs that go well with others that the user liked recently.
Business Case:
The motivation behind creating this recommendation engine is similar to the motivation behind playlists; there may be a group of songs that the user would like to listen to now and a group that the user doesn't want to hear soon. This may be based on several factors such as the user's current mood, the preferences of anyone else nearby, and whether the user is too busy to listen to a catchy and distracting song. The recommendation engine would remove the need for the user to spend time making and maintaining complicated playlists.
Even though there exist projects that aim to classify a song or movie and find songs similar to it, it does not appear that other recommendation engines use as much information about timing.
Project Stakeholders:
The project stakeholders include the two SD&D professors that are teaching an entire class devoted to the success programming projects like this one and to the improvement of design and documentation in the process. The remaining stakeholders are the four of us students who will be investing time into the project.
Major Features:
One major feature of the program will be to predict songs that the user would like to listen to.
The program will also have to use a variety of input from the user to maximize convenience. This may include information such as the time that any song is skipped, chosen, played, rated, upvoted, downvoted, or stopped.
It is also desirable that the program use higher-level input from the user, such as choosing a certain class of songs.
Also to maximize convenience, it is preferable to show to the user a playlist of expected songs, and to update it whenever the user takes an action that changes it.
Major Risks:
If our user interface is cumbersome then it is possible that users will not bother to become familiar with it.
If our recommendation engine is not intelligent enough, then users may choose not to use it in and instead select songs or playlists manually.
User Scenarios
A list of the features of the proposed software. Include two scenarios that describe a user in your target audience using your software to satisfy one their goals. Include a description of the persona, details of their goal, details of the user interface with which the user interacts, and the sequence of steps they go through with the requisite system responses to accomplish their goal.
User Scenario 1:
Joe is a grad student working in bioinformatics. He likes to listen to music whether he is working or partying. While at work where he needs to concentrate, he does not want very many loud, catchy or distracting songs. He would probably even prefer to occasionally have a minute or two of silence between songs. However, he likes for there to be a high-energy song every once in a while because people get more work done when they take occasional breaks.
Because he listens to the music player every day at work, he is quite familiar with it. He has switched to the more-complicated user interface where the rating of a song is a float, not just an integer 1-5. Every morning, he starts the music player and selects that his current state is "work" as opposed to "play" or "party". Then he clicks the play button and proceeds with work. Occasionally he will skip a song or assign a rating to a song. At lunch he switches his state to "play", and after his break he switches it back to "work".
User Scenario 2:
User Scenario 2 has not been written yet.
Project Schedule
A detailed schedule of the phases and iterations of your project. You must include iterations and dates for the development of each use case or feature, as well as estimates of the time required to complete each item on the schedule. The schedule must show the specific dates each phase and iteration ends. Also include preliminary details and timing of the tasks included in completing your project.
A list of all Important Dates for the class may be found here
Mar 22 (Tues) Planned end of Construction iteration 1
Preliminary user interface completed, with at least one button
Preliminary algorithm implementation that chooses songs but not necessarily intelligently
Apr 05 (Tues) Planned end of Construction iteration 2
We have not yet chosen what will be done for this date
Apr 19 (Tues) Planned end of Construction iteration 3
Fully functional user interface
User can give a score to a song at any time
Fully functional