JamminGo
Requirements:
Functional Requirements:
Play music
Navigate playlist
After playlist ends go to next folder or random song
Recommendations
Multi-level filtering (search)
Sorting
Arbitrary tags
Replay Gain
Equalizer
Gapless playback
Lots of filetypes
Streaming services
o Internet radio
o Pandora
o Plug-in architecture for more
Bluetooth support
o Button recognition
o Auto start on connection
o Auto stop on disconnection
Random/Shuffled playback
Non-functional Requirements
Low latency (<50 ms response rate)
Usable while distracted/moving
o Large buttons (Finger to thumb sized buttons on a 4in screen)
o Simple interface (<6 buttons per screen)
o High contrast
Small executable size (<50 MB)
Small memory size (<100 MB)
Buffering to support gapless playback and internet streaming (15-30s buffer)
Relevant recommendations
No major memory leaks (<200 MB RAM usage after 7 days of constant playback)
Infrequent crashes (<1 crash per 7 days of constant playback)
Lists plenty of user features, and pertinent non-functional requirements. Includes details on non-
functional requirements, which will make validation possible. No contradictory or impossible
requirements, realistic non-functional requirements.
Architecture:
Design Patterns:
Model-View-Controller: Supports a GUI with a clean separation from the backend audio processing.
Client-Server: Connect the app to internet radio servers.
Pipe & Filter: Allows music list to be filtered repeatedly. Allows music to be sent through multiple
modifications (Replay Gain, Equalizer) before output.
Singleton: Single instances of the audio buffer, and settings.
Memento: Make a storable copy of the settings.
Façade: Produce a consistent interface for the plug-in architecture.
Iterator: Provide methods for iterating through a playlist.
Lists several design patterns and describes how they will be applied.
Required Systems/Relationships/Levels of Abstraction:
Model View
Controller
Now
Playing
LibraryPlaylistEqualizer
OptionsStreaming
Recomme
nded
File Info
A
u
d
io
B
u
ff
e
r
In
p
u
t
P
a
rs
e
r
Library
Playing
Taps Swipes
Bluetooth
Figure 1: High Level System Architecture
Audio Buffer
Input Parser
File ReaderNetwork
Streaming
Service
Audio Playback
System
Audio Filters
Audio Queue
Figure 2: Audio Decoding and Playback Architecture
Includes two different levels of abstraction for the system. Each level of abstraction includes its own
systems and relationships. The high-level view also gives some insight into its components. Would be
nice to show even more perspectives.
Interfaces:
Programmatic Interface:
Database
Files
Services
GetAllFiles()
GetAllServices()
GetInfo(Item)
GetFileName(Item)
Filter(List, Criteria)
Playlist
Items
ListInfo()
GetInfo(Index)
Append(Item)
Insert(Item, Index)
Remove(Index)
Move(Index, Index)
View
Controller
Audio Queue
Figure 3: Class Diagram for the Database and Playlist
Simple class diagram that shows the interfaces that the media database and the playlist provide to other
parts of the program. Functions include a description of their required parameters. Would be nice to
show additional classes—perhaps in a different area of the program.
User Interface:
Scrolling Title – If
Artist, Album, Oth
Denver – Take Me H
Bach – Air on a G Str
rosmith – Dream On
Beatles – Sgt. Pepper
Beatles – Hey Jude
Jensen – Run Rabbit
Matchbox 20 – A.
CLANNAD – 潮鳴り
Final Fantasy – Prelu
Figure 4 Now Playing Window Figure 5: Playlist Window
User interface that matches the non-functional requirements. Two screens should be considered the
bare minimum, unless the program doesn’t rely heavily on a UI.
Testing & Verification:
Functional requirements:
1. Unit testing can handle most parts, use mock objects for initial tests.
2. Automated nightly builds with integration testing.
3. Automatically create random “music” files to automatically test nightly builds.
4. Use non-development personnel (CEO, janitor) for black box testing.
5. Test on developer owned and common devices with personal music collections. (Alpha test)
6. Limited beta test with friends/family/enthusiasts.
7. Large scale beta test with paying customers (guinea pigs).
Non-functional requirements
1. Add timing to automated testing for latency.
2. Check package size and execution size.
3. Design buffer to be large enough to hold >15s of data, even for high-resolution audio types.
4. Use non-development personnel (janitor, CEO) to check the simplicity of the UI.
5. Listen for recommendation complaints or accolades from the peanut gallery.
6. Add memory usage tracking to the automated tests.
7. Add crash tracking to the automated tests.
8. Run profiling tools weekly to catch latency and memory hotspots early.
Testing and validation procedures are extensive and multi-pronged. They appear likely to catch most
bugs and other problems before release. Non-functional requirements are easily verified thanks to the
details on the original requirements.
Development Strategies:
The core of the system should be designed ahead of time to ensure low latency interaction and
playback. So, we will use a plan-oriented strategy at the beginning while we are focusing on the audio
engine. Most of the other parts can be built using an iterative strategy. Adding audio sources (filetypes
and streaming), tag support and filtering can be done in small chunks, and in whatever order we want.
The GUI will likely need multiple iterations, so it would also work well with an iterative development
strategy.
Modern development tools will be helpful for eliminating bugs early on. We will also use pair
programming to help catch algorithmic issues early on. Design by contract will work very well for a lot of
the non-core parts. This will ensure that we have strict expectations for what they do, so we know they
will interface with other parts with a minimum of fuss.
Development strategy displays a good understanding of the issues likely to arise during the project and
chooses a core development strategy to match. Other tools and approaches are also brought in to
smooth the development process. Not every method or tool will work for every project, but adding more
of them and increased explanation of why they are applicable would improve this further.