The users

From smultron.org

Jump to: navigation, search

In order to gather all requirements, you will need a list of all the people involved in your project. This list should not be limited to people actually participating in your station, but should include your listeners, performance rights organizations and even people who do not want you to succeed, e.g. your competitors or political enemies. Anybody participating in, or in any way affected by, your radio station is a user, or technically speaking, a stakeholder.

Stakeholders come in great numbers and many flavors. Grouping them in some way is necessary to keep track of who you have interviewed or who has skipped the meetings, and also to keep the number of workshop participants at a reasonable level. Here are some example groupings:

Contents

Areas of involvement

Organizational area

This area includes your sponsors, such as the station founders or association board members and your project manager.

Studio operators

All users who have access to the studio.

Editor in chief
Responsible for the overall schedule concept. This concept can be a weekly grid of programs, updated every 3 months, or a more general program slot grid, listing only guidelines the individual programs can fulfill.
Editors
Editors are responsible for the daily program schedule, or for certain slots.
DJs, presenters
Spoken content, playlists, recordings of DJ sets, livesets and concerts.

Production team

Groups of people involved in the conceptualization and production of the radio station, such as sound mastering technician, analog studio technician, webmaster, software developer, system administrator.

Environment

Anybody who is not part of your organization, e.g. your listeners, or external organizations.

Listeners
FM radio listeners, online stream listeners, podcast downloaders, website users
Regulating organizations
Broadcast regulation board, performance rights organization

Of course, individuals can fulfill several roles and thus be grouped in several areas.

Responsibilities and Roles

Another, complementary, way of looking at users is to examine the responsibility embodied in the user. Plotting these responsibilities in a table can help spotting unassigned responsibilities as well as potential conflicts. Knowing these responsibilities, the system administrator can create roles and grant permissions accordingly.

Area of Involvement Goal Editorial line Program Schedule Audio asset Playlist Text Usability Finance Legal Functionality Security
Organizational area
board member xxx
project manager xx
Studio operators
Editor in chief xxxx
Editors xxx
DJs, presenters xxx
Production and services
analog studio technician x
webmaster xxx
software developer xx
system administrator x
Environment
listeners
Regulating organizations x

The extent to which responsibilities are delegated to listeners depends on the stations editorial concept. On some stations, listeners are passive. On other stations, listeners can compose playlists or edit the schedule and on others, listeners can upload content.

There are a number of potential conflict to be resolved. One such potential conflict is between DJs and editors. DJs can upload files into the archive, but editors can delete them, because they are responsible for implementing legal constraints enforced by regulating organizations. DJs can schedule a playlist, but editors can de-schedule it, if the playlist does not fit in the editorial concept for a particular time slot.

The extent to which this conflict resolution should be implemented in software is a matter of station policy. Conflicts can also be resolved through conventions or workflows. Whichever solution is opted for, there should be a feedback mechanism so that the parties involved can communicate with each other on the particular issue.

Personal tools