name:Requirements
Due to the short amount of time that this project is to be completed in, I will be using the MoSCoW technique to categorise the requirements by their importance. I aim to implement the most important requirements first ensuring that they work before proceeding onto those of lower priority.
| # | Summary | Description |
|---|---|---|
| Must have | ||
| 1 | Playback on specific device | It must be possible to select an item of audio to play on a specific decice |
| 2 | Synchronised audio playback (Party Mode) | The solution must be capable of synchronised playback of an audio file between 2 or more devices |
| 3 | Manual Master / Slave ability | Devices must be able to either be assigned as a Master or Slave device. The master device will provide the clock (for party mode) and playback commands to the slave devices on the network. |
| 4 | Command line facility | The software should be capable of being started (with the above functionality in place) via the command line |
| Should have | ||
| 5 | Service Discovery Mechanisms | The Devices on the network should be capable of discovery and configuration without user interaction. For example, if a master device has been set-up, a new slave entering the network should automatically discover the master and configure itself and be available to use straight away. |
| 6 | Automatic Master / Slave using service discovery | As well as specifying whether the device should be a master or slave device via the command line, the software should be capable of ascertaining whether it should configure itself as a master or slave automatically. |
| 7 | Cloud User Interface | A web interface should be available to allow a user to control their devices including the setup of device names and the selection of content to be played through each device. |
| 8 | Purpose built Linux SD card image | A fully built image that when copied to an SD card and inserted into the Raspberry Pi will be fully functional. The only user interaction will be to copy the image to the SD card and turn the device on. |
| 9 | Javascript controls on the cloud user interface | In order to make the user experience richer when controlling a device through the cloud user interface, JavaScript should be used to handle actions committed. This allows for pages to adapt to the user's input quicker and also provides the ability to update the control elements (e.g. volume control) if they change. |
| Could have | ||
| 10 | A Packaged version of the application | A packaged version of the final solution could be made available that can be installed on practically any Debian system. This could be hosted in a custom repository. |
| 11 | Allow control of the devices via UPnP and/or AirPlay | The devices could be configured to render media via UPnP or Airplay allowing them to play audio from external sources such as mobile phone, tablets and other media servers. |
| 12 | Ability to play music from attached USB device | A user could store their audio on USB devices (such as flash drives). This music could then be made available for playing when the user plugs the USB device into their master device |
| 13 | Ability to play music from a network storage device | A user could store their audio on a networked storage device. This could be discovered by the master device and the audio made available for playback on all devices. |
| 14 | Automatic audio metadata discovery | In order to display a user audio collection is a user friendly way, the audio files could be scanned for their metadata. This metadata could then be used to display the user's collection on the user interface. |
| 15 | Ability to run as Daemon | Rather than having the app running interactively, the application could be daemonized allowing it to be run as a service. As the application is controlled entirely through the cloud user interface interactivity is not required. Having the ability to run the application as a service also means that the image can be configured to run at startup using an init script. |
| Wont have | ||
| 16 | Security improvements | Due to the short amount of time that has been assigned to complete this project in, tight security improvements will not be possible. However with more time the system would use public/private key exchanges in order to provide authentication, confidentiality and integrity as well as web security measures such as XSRF protection. |