MP3 Player Case Study PDR

Daniel Fortino

Introduction: The MP3 Player

- The MP3 Player provides a simple, portable way to store, manage and play digital
audio files through external headphones or speakers. This includes the ability to
store and browse playlists, as well as browse a library of music stored on the
device.
- Modern MP3 Players have lost their roots of simplicity, and often include
additional features that reduce battery life, increase complexity and take away
from the devices effectiveness.
- This case study focuses on bringing the MP3 player back to its roots in simplicity
and portability.

Customer Use Case 1: Playing Music

Customer Use Case 2: Changing Settings

Customer Use Case 3: Syncing from Computer

Maintenance Use Case: Troubleshooting Errors

External Systems Diagram

System Requirements: Input

1. The MP3 Player shall accept Power State controls (Power On/Off) from the user.
2. The MP3 Player shall accept Activity Selection (Music, Playlists, Settings) from
the user.
3. The MP3 Player shall accept Settings Input (Setting Selection, Setting Value,
Setting Confirmation) from the user.
4. The MP3 Player shall accept Playlist Selection from the user.
5. The MP3 Player shall accept files from the computer via USB.
6. The MP3 Player shall accept charge from the computer via USB.
7. The MP3 Player shall accept fixes from Maintenance.

System Requirements: Output

1.
2.
3.
4.
5.
6.
7.
8.
9.

The MP3 Player shall provide Maintenance Information to Maintenance.

The MP3 Player shall provide File Information to the computer via USB.
The MP3 Player shall provide Connection to the computer via USB.
The MP3 Player shall provide Analog Audio Signal to the Headphones via 3.5mm
audio jack.
The MP3 Player shall provide Song Information to the user.
The MP3 Player shall provide Request for Activity to the user.
The MP3 Player shall provide List of Songs to the user.
The MP3 Player shall provide List of Playlists to the user.
The MP3 Player shall provide Settings Output to the user.

System Requirements: External Interfaces

1. The MP3 Player shall utilize USB to communicate with the computer.
2. The MP3 Player shall utilize analog 3.5mm audio jack to transmit audio to
headphones.

System Requirements: Functional

1. The MP3 Player shall store files transferred from the computer.
2. The MP3 Player shall allow a user to browse files stored on the device.
3. The MP3 Player shall allow a user to play a selected file of supported type through
the headphones.
4. The MP3 Player shall receive user input and provide an appropriate response.
5. The MP3 Player shall provide features for maintenance.

System Requirements: Non-functional

1. The MP3 Player shall weigh no more than 4.5 ounces; the design goal is 3.5.
2. The MP3 Player shall last no less than 12 hours on a full charge; the design goal is
18.
3. The MP3 Player shall store no less than 64 GB of digital audio files; the design
goal is 128 GB.
4. The MP3 Player shall cost no more than $200 to produce; the design goal is $150.
5. The MP3 Player shall respond to user requests in no more than 0.5 seconds; the
design goal is 0.25 seconds.
6. The MP3 Player shall require that the user navigate no more than 3 menus to
begin playing music.

System Context Diagram

Interface Block Diagram: USB

Interface Block Diagram: 3.5mm Audio Jack

Physical Block Diagram: MP3 Player

First Level Functional Decomposition: MP3 Player

User Interface: Input Requirements

1.
2.
3.
4.
5.
6.
7.

The User Interface shall accept power from the battery.

The User Interface shall accept activity selection from the user.
The User Interface shall accept fixes from Maintenance.
The User Interface shall accept playlist selection from the user.
The User Interface shall accept Settings input from the user.
The User Interface shall accept song selection from the user.
The user interface shall accept Processed Data from the processor.

User Interface: Output Requirements

1.
2.
3.
4.
5.
6.
7.

The User Interface shall provide user commands to the processor.

The User Interface shall provide maintenance information to Maintenance.
The User Interface shall provide request for activity to the user.
The User Interface shall provide list of songs to the user.
The User Interface shall provide list of playlists to the user.
The User Interface shall provide song information to the user.
The User Interface shall provide Settings Output to the user.

User Interface: Functional Requirements

1. The User Interface shall receive user input via the control pad.
2. The User Interface shall display output via the screen.
3. The User Interface shall send and receive relevant data from the processor.

User Interface: Non-functional Requirements

1.
2.
3.
4.

The User Interface shall weigh no more than 0.75 ounces.

The User Interface shall use no more than 600 mAh of power per 18 hours of use.
The User Interface shall cost no more than $30 to produce.
The User Interface shall send commands to the processor in no more than 0.05
seconds.
5. The User Interface shall require that the user navigate no more than 3 menus to
begin playing music.

User Interface Context Diagram

Second Level Decomposition, User Interface

Integrated Circuit: Requirements

1. Input
1.1.
1.2.

The Integrated Circuit shall accept user commands from the Control Pad.
The Integrated Circuit shall accept Processed Data from the Processor.

2. Output
2.1.
2.2.

The Integrated Circuit shall provide Processor Commands to the Processor.

The Integrated Circuit shall provide Display Information to the screen

3. Functional
3.1.

The Integrated Circuit shall convert User Commands to Processor Commands.

3.2.

The Integrated Circuit shall convert Processed Data to Display Information.

Integrated Circuit: Non-Functional Requirements

1. The Integrated Circuit shall weigh no more than 0.15 ounces.
2. The Integrated Circuit shall use no more than 50 mAh of power per 18 hours of
use.
3. The Integrated Circuit shall cost no more than $3 to produce.
4. The Integrated Circuit shall send commands to the processor in no more than
0.03 seconds.

Integrated Circuit Context Diagram

System Assessment: The Good

- Portability: One of the most important criteria when analyzing this system. With a
weight of 3.5 ounces and a battery life of up to 18 hours. This is made possible
because of the systems incredibly simple architecture
- Simplicity: Both the physical and functional architecture of this device are kept
simple by remaining true to its core design principle and avoiding unnecessary
features.
- Openness: Another area in which this system excels is in using standardized, off
the shelf parts. USB and 3.5mm Audio Jacks are the widely accepted standards for
data and audio transfer.

System Assessment: Challenges

The most challenging design requirement to implement for this system would likely be
the requirement that the user never be more than 3 menus away from music. This
increases simplicity greatly for the user, but implementation would require careful
consideration when designing the User Interface.

One thing that could make this easier would be to add a hardware button that returns
the user to the main menu regardless of where in the menu hierarchy they are.

Process Assessment: CORE and other Takeaways

- This process is recursive and nonlinear, making it a perfect candidate for systems
engineering tools like CORE.
- CORE makes iterating on architectures and relationships easy and eliminates the
need to do much of the work again after every change.
- This project initally looked at the iPod shuffle, but that proved too simple to
decompose to two levels and still have substance. CORE allowed me to use a more
feature-rich baseline while salvaging most of the original architecture, building on
top of it rather than replacing it.