754 Sys Req Spec Final Gatz

RADIO DIGITAL ARCHIVE REPOSITORY
SYSTEM REQUIREMENTS SPECIFICATIONS
BUSINESS OWNER - WNIJ/WNIU RADIO]
PROJECT MANAGER – JANET GATZ
ORIGINAL PLAN DATE: JANUARY 18, 2017
REVISION DATE: APRIL 30, 2017
REVISION: 3.0
Radio Digital Archive Repository System Requirements Specifications
REVISION HISTORY
REVISION NUMBER DATE COMMENT
1.0 August 14, 2007 Original DoIT PMO Document
1.1 April 10, 2017 Update for RDAR project
1.5 April 20, 2017 Added Use Cases, Introduction
1.8 April 22, 2017 Completed Operational Concepts
2.0 April 28, 2017 Completed Non-Functional Requirements
2.5 April 30, 2017 Completed Functional Requirements
3.0 May 1, 2017 Completed final document
Page 2 of 35
Table of Contents
REVISION HISTORY ............................................................................................................................................. 2
TABLE OF CONTENTS .......................................................................................................................................... 3
INTRODUCTION ................................................................................................................................................. 5
PURPOSE OF THIS DOCUMENT .......................................................................................................................................... 5
GOALS OF THE PROJECT................................................................................................................................................... 5
SYSTEM SCOPE .............................................................................................................................................................. 6
CLIENT, CUSTOMER AND OTHER STAKEHOLDERS .................................................................................................................. 6
USERS OF THE PRODUCT .................................................................................................................................................. 6
ASSUMPTIONS AND OTHER RELEVANT FACTS .................................................................................................... 7
FUNCTIONAL REQUIREMENTS ............................................................................................................................ 7

BEHAVIORAL REQUIREMENTS ........................................................................................................................................... 7
DATA REQUIREMENTS..................................................................................................................................................... 8
INTEGRATION REQUIREMENTS .......................................................................................................................................... 8
USER INTERFACE REQUIREMENTS ...................................................................................................................................... 8
Screen Layout Requirements ................................................................................................................................ 8
Reporting Requirements ....................................................................................... Error! Bookmark not defined.
NON-FUNCTIONAL REQUIREMENTS ................................................................................................................... 9
USABILITY REQUIREMENTS............................................................................................................................................... 9
Ease-of-use Requirements.................................................................................................................................... 9
Documentation Requirements ............................................................................................................................. 9
Safety Requirements ............................................................................................................................................ 9
PERFORMANCE REQUIREMENTS ........................................................................................................................................ 9
Availability Requirements .................................................................................................................................... 9
Responsiveness Requirements ............................................................................................................................. 9
Reliability Requirements ...................................................................................................................................... 9
Capacity Requirements ...................................................................................................................................... 10
Scalability Requirements .................................................................................................................................... 10
Disaster Recovery & Business Continuity Requirements .................................................................................... 10
SECURITY REQUIREMENTS.............................................................................................................................................. 10
User Security Requirements ............................................................................................................................... 10
Data Security Requirements............................................................................................................................... 10
LEGAL REQUIREMENTS .................................................................................................................................................. 11
Notification Requirements ................................................................................................................................. 11
Privacy Requirements ......................................................................................................................................... 11
OPERATIONAL REQUIREMENTS ....................................................................................................................................... 11
Hardware Requirements .................................................................................................................................... 11
Software Requirements ...................................................................................................................................... 11
Network Requirements ...................................................................................................................................... 11
Architectural Requirements ............................................................................................................................... 12
Data Management Requirements ..................................................................................................................... 12
Production Support Requirements ..................................................................................................................... 12
Software Licensing Requirements ...................................................................................................................... 12
OPERATIONAL CONCEPTS.................................................................................................................................. 12
Page 3 of 35
FUNCTIONALITY (BEHAVIORAL) ....................................................................................................................................... 12

Use Cases ........................................................................................................................................................... 12
Functional Analysis Model ................................................................................................................................. 12
DATA MODELS ............................................................................................................................................................ 25
USER INTERFACE PROTOTYPES ........................................................................................................................................ 30
REQUIREMENT CONSTRAINTS & DEPENDENCIES ............................................................................................... 34
DESIGN CONSTRAINT .................................................................................................................................................... 34
PROJECT CONSTRAINT................................................................................................................................................... 34
REFERENCE MATERIAL ...................................................................................................................................... 35
ACRONYMS AND GLOSSARY .............................................................................................................................. 35
Page 4 of 35
INTRODUCTION
PURPOSE OF THIS DOCUMENT

In 2015, WNIJ and WNIU Radio in DeKalb, Illinois began the task of organizing,
digitization, and cataloging of the stations many reel to reel, data audio tapes, and mini-disks
that had been stored in their programming library over the past forty years. They also began
sorting through the boxes of paperwork that have accumulated over the decades. The goal of
this digitization project was both to clean out old and unneeded items, as well as discover
and preserve the current and older programming that was created at the station. The project
officially began in mid-summer of 2015, and completed the digitization of process by
January 2017.
Users have noticed that the current methods of searching and accessing the digitized audios
are not ideal and make using the archive trying. The files are available in a server connected
to the intranet. While this makes access easy for everyone, many cannot differentiate one file
from another without assistance. The catalog showing what each file contains is a multipage
Microsoft Excel spread sheet. Most of the entries contain only the information that was
available from packaging of the tape or reel it originated. Those who try and use the digital
information often need to know what the name of the original reel or DAT to find its
corresponding file. The station has been unable to complete its goal of allowing their
listeners access and experience these older audios. The Radio Digital Archive Repository
(RDAR) is designed to fix many of these problems.
GOALS OF THE PROJECT

The RDAR is designed as a centralized hub for both employees and the station’s patrons to
access current and older programming. The system itself will benefit the station by granting
the station a unified area for staff to access older news stories and raw interviews if needed.
The creation and incorporation of this system would have the greatest benefits to our
listeners. Regular updates will allow our users to listen to their favorite DeKalb based
programming even if they couldn’t hear it live. The availability of older programming and
news shows are a boon to students, as well as those wanting to know more about the history
of our town, and NIRIS users will be able to access a back catalog of almost two decades of
audio readings. This can result increased traffic to the WNIJ web site, as well as more live
listeners. This will benefit the station during the seasonal pledge drives.
The digitization of the stations’ older programming may also benefit the station itself. With
the recent retirement of several nationally syndicated shows, the station has the dangerous
possibility of having hours of dead airtime. The older programming can be replayed as part
of a new program highlighting past news events in the area. While this would not be a
financial gain to the station, the recycling of older programming will be cost effective. There
is also a potential financial benefit. This system can be offered to other organizations to be
used in their own digitization projects.
Page 5 of 35
SYSTEM SCOPE
This system is not replacing or updating any previous system. It will encompass all current
and future audio data storage for the station and its employees. Outside of the statin, the
RDAR will serve as a way to connect the public to news and special interest stories that
occurred in DeKalb’s history. Public use will be the primary focus of the system, since
employee use will be limited outside of storage and organization. Staff will use the system to
access older news stories for context in current programming, or as a sound bite for a future
work or retrospective. However, employee use will sparse outside of those areas.
CLIENT, CUSTOMER AND OTHER STAKEHOLDERS

Client- WNIJ Radio and its affiliate station WNIU.
Customer- Staff of WNIU/WNIJ, including reporters, producers, general staff and the station
manager. Other users include the WNIU/WNIJ listeners and any member of the public that
could use the information within the system for research purposes.
Other Stakeholders- The Regional History Center is interested in assisting in the creation of
this system. They would be like to possibly use the system for their own audio database.
They would also like to know if this information is available so they can send any student
researchers to look there.
USERS OF THE PRODUCT

There are two main users that will interact with the RDAR system; employees of
WNIJ/WNIU, and the public. Public users will access the system to listen to older
programming. They will be able to search for specific shows, such as Art Sounds, or by a
subject or person. Once they find what they are looking for, the user would be able to stream
the audio. They will also be able to read information on when an audio aired on the station,
the show host, the reporter, etc. Many listeners may use the service for research into news
stories that are told from a different perspective than those of national radio and television.
Staff may use the system daily for several different reasons. Someone may use the system to
upload their most news bits to the database for storage. Others may look to the system to
find information on individuals from the town or county that have been in the news multiple
times. This would allow them to cite previous interviews in their current stories, or collect
quotes for a retrospective. Other members of staff may wish to use the system in a similar
manner to the public.
Page 6 of 35
ASSUMPTIONS AND OTHER RELEVANT FACTS

This specification assumes that WNIJ/WNIU wishes to have a method to use the already
digitized audios in a way that would benefit the station. This assumption is based on the
time, effort, and funding used to organize and complete the digitization process in the first
place. This assumption is also based on the goals created by the head of the original
digitization project about what would be done with the files after completion.
The greatest barrier for our goals is financial. Assistance to WNIJ/WNIU by the federal
government is currently in flux. The Illinois budget crisis has also resulted in a heavier
reliance on donations from listeners in the day to day finances of the station.
FUNCTIONAL REQUIREMENTS
BEHAVIORAL REQUIREMENTS
The system would be accessed through the internet on the WNIJ website and through a
mobile application. Users would first gain access to the system via a log in screen. If the
login portion of the system is damaged, users will be unable to access the system at all. New
visitors will need a valid E-mail address to allow them to fill complete signing up for the
system and picking a login name. Once the sign in is complete, the system will send an E-
mail asking for validation before allowing the user to continue. If any of these steps are
broken, the system will give an error message and the user will be unable to create a log in.
Specific staff logins will be able to create, edit and delete other logins for users based on
their security clearance.
Once in the system, users will be able to find past files based on multiple variables. A user
can search by the show it was broadcasted from, the reporter who compiled it, the subject
matter, and by interviewee. The RDAR system also contains a filtering system so users can
edit out results. An example is filtering out all completed news articles and leaving only the
raw interviews, or showing all results between a specific time frame. Searching for items
that do not exist in the system will turn up a “file not found” result, with the option of trying
to search again.
When a user chooses the specific audio, they wish to listen to, the streaming page in the
RDAR contains additional information on the specific file. Each link will open a screen
showing notes about the specific file. It will note if there are audio errors caused by
deterioration of the tape, a bad transfer, or even errors when it was originally recorded. If the
link to the audio file is broken, the streaming page information on the file will show, but the
button to begin the stream will show an error. Staff Users will be able to download other
audio files from the individual streaming page if links are connected.
Uploading new files is an option available based on the security access of a log in. The staff
member will need to fill out the metadata forms for the file before uploading it. Any empty
boxes in the metadata implementation area of the upload screen will result in and error. The
Page 7 of 35
screen will reset to a blank upload screen and require the user to try again. If the user does
choose to upload the file in an audio format not recognized by the system, it will not upload
to the database. A file error message will show on screen and the user will need to add a file
in the correct audio formats before they can continue. If there is an error with a log in, it will
default to the ‘public’ security access. Public security access will only allow users to search
and listen to audios. They will be unable to upload, edit, or delete any files in the system.
DATA REQUIREMENTS
The RDAR contains six modules that interact with multiple internal data files throughout the
system. Most interaction between the data access layer and the user interface will be
relatively quick at around 2 seconds’ real time. However, increased latency may occur
during a high-volume period if more than the average number of users are streaming the
same files. Also, the data accumulation module will often be interacting with all 4 databases.
It must accumulate data about user interaction with the databases and then store it in the
interface and transaction database. In turn, the system report module will be interacting with
the interface database.
INTEGRATION REQUIREMENTS
The online edition of the RDAR requires cookies to be allowed to properly work on the
user’s compute system. This is so the streaming service the system uses can integrate with
the computer properly. The mobile application requires the use of an Android or Apple
phone to work correctly. Users with neither will only be able to access the system via the
world-wide web.
USER INTERFACE REQUIREMENTS

SCREEN LAYOUT REQUIREMENTS
Screen default layout will be a 1366 x 738 ratio for the system’s online screens. The site’s
banner is at the top of the screen with the main menu right below. The menu is horizontal, with
the home link on the far left. After the home link is a drop-down menu labeled ‘browse shows’.
The drop down allows users to scroll through the different shows available to listen to. Next is
the ‘interview’ drop-down menu. This allows users to choose between raw audio of interviews
or the edited and aired versions, as well as browsing by the name of the interviewer or their
guest. After the interview menu is the upload button followed by the search tab. Only staff will
be able to click on the upload link. Below the search tab is the link to the login screen. Next to
the login link is a small question mark in a circle. This will lead to the frequently asked
qustions. The menu options will be in the same position each page for ease of use.
Advertisements and links to the main WNIJ home page will be on the right side of the screen.
Page 8 of 35
NON-FUNCTIONAL REQUIREMENTS
USABILITY REQUIREMENTS
EASE-OF-USE REQUIREMENTS
This system has been designed to give the user a simple interface to make working
through the site as simple as possible. The system is designed with the average WNIJ
user in mind. The main menu contains easy to read directions to help guide users to
where they wish to go. A novice or journeyman level of computer skill is required to
work all parts of the system successfully.
DOCUMENTATION REQUIREMENTS
The public version of the RDAR should require no user manual to be produced.
However, there will be a help button available with several answers to common questions
that a user may have while navigating. The staff interface contains many more working
parts. As such, a pdf user manual will be available. It will contain a detailed guide to the
system in case they are confused or get lost. However, most questions should be
answerable by the online frequently asked questions.
SAFETY REQUIREMENTS
The RDAR may cause loss, damage, or harm in the case of a data breach or system crash.
Increased password security at the log in level, along with an encryption algorithm in the
data access layer of the system should help safeguard possible data breaches. Regular
system backups will help insure little to no loss of information in the case of a system
crash or data purge.
PERFORMANCE REQUIREMENTS
AVAILABILITY REQUIREMENTS
System should be online approximately 154 hours in a week, with peak times occurring
between 1:00pm and 5:00pm. The system should be down on average no more than two
hours a day for backups and maintenance.
RESPONSIVENESS REQUIREMENTS
The system should have an online response time of approximately 2.5 seconds. System
reports should have a deadline of no less than once every 7 days. Streaming response
times should be delayed no more than 5 seconds.
RELIABILITY REQUIREMENTS
The RDAR system needs to be reliable. Average mean time between failures (MTBF) is
approximately once every 65 days.
Page 9 of 35
CAPACITY REQUIREMENTS
Current CPU capacity is an Intel Pentium i7 with 8GP memory. It holds 2.5T disk space
for all audio data, and an additional 3 1T hard drives for the other databases. The
network bandwidth is approximately 5196.
SCALABILITY REQUIREMENTS
The RDAR is designed to keep its current system requirements for some time. Any
required increase in capacity will occur immediately after a regular system backup. The
database disk space will be increased according to need and the system rebooted. The
reboot will use the most recent backups to integrate the system smoothly. Estimated loss
of time is 24-36 hours.
DISASTER RECOVERY & BUSINESS CONTINUITY REQUIREMENTS
All backup data will be stored offsite in the event of a disaster. Once every 30 days, the
RDAR will have a complete off site backup. This backup will be stored at the Regional
History Center at Founder’s Library at Northern Illinois University. In case of complete
destruction of the system databases, these backups will be used to rebuild. Smaller, in-
house backups of systems will occur once every 7 days. In event of a complete system
shut down or data purge, the system will be rolled back and updated with these backups.
SECURITY REQUIREMENTS
USER SECURITY REQUIREMENTS
Public users wishing to log into the system will be required to fill out the sign-up form on
the main screen. Staff users will have their login and security clearance created for them
by the Station Manager or System Administrator after they have completed training and
orientation. Both public and staff users will require a valid e-mail address. Staff users
will be given one when their login is created. All users must choose a password that is at
least 8 characters and containing one capital letter, one symbol, and one number. Once
the sign is complete, a validation e-mail will be sent. The user will be able to begin using
the system once the email validation is complete.
DATA SECURITY REQUIREMENTS
The system itself also has varied security access. When all other groups create, update,
read or delete the other operations, the system creates and collects metadata. The system
will then create and update system reports based on this metadata to be read by the
Station Manager and System Administrator. The databases will back itself up once a
week as decided by the System Administrator. The system will perform rolling updates
to ensure all databases are not lost during a system crash. These updates will occur no
more than once a week and no less than once a month.
Page 10 of 35
LEGAL REQUIREMENTS
NOTIFICATION REQUIREMENTS
All news reports are the property of WNIJ Radio and their original creators. Any
quotations or use of these files for research is allowed as long as the original creators and
the station are properly cited. Any individual using a quote from a previous interview
must cite the date and original interviewer of the piece. Use of the RDAR by non-
registered users is prohibited.
PRIVACY REQUIREMENTS
WNIJ Radio retains the right to accumulate data on user’s use of the system for purposes
of in house analysis. This information may be used for listener trends and station
analysis. WNIJ will not use the information accumulated from the system to sell to
outside entities.
OPERATIONAL REQUIREMENTS
HARDWARE REQUIREMENTS
This system will run on any windows compatible PC with a Pentium i5 core and
Windows Vista or greater. The system will also work on any Apple product with an OS
of Mountain Lion or higher (OS 10.8). The Application can be used on any smart phone
with the correct software level OS installed.
SOFTWARE REQUIREMENTS
This system will run on any windows compatible PC with a Pentium i5 core and
Windows Vista or greater. The system will also work on any Apple product with an OS
of Mountain Lion or higher (OS 10.8). The Application can be used on any smart phone
with the correct software level OS installed. Changes that have occurred with the
Windows and Apple operating systems post XP and Lion make using the system on
computers with older operating systems difficult.
The main system interface must be used on Google Chrome version 32.0.1700 or greater,
Firefox version 50.0.5, Microsoft Edge, or Safari. The mobile application for this system
can be used on any hardware capable containing a current version of the Apple OS, or
Android OS.
NETWORK REQUIREMENTS
All audios are required to be in MP3 format for streaming. The stream will be using an
HTTP as a standard and streaming at approximately 300 Mbit/s. All users will require an
internet connection to access the RDAR system’s main page, either by mobile device or
website.
Page 11 of 35
ARCHITECTURAL REQUIREMENTS
The system architecture will be based through both a web page and through a mobile
application. To help our users, the architecture is designed using the thin client/fat server
model and will contain three tiers. This will allow the users a user-friendly access, but
will result in more work for the system itself. This method is also useful for any possible
expansion of the system in the future. The RDAR system will need assistance if it moves
from its original home.
DATA MANAGEMENT REQUIREMENTS
The RDAR collects data of all user interaction with the system. It retains this data in one
of the 4 system databases. The system uses and encryption algorithm to ensure the
security of both the users information and the system information. The RDAR database
will back up all data for a minimum of 1 year before purging. Data backup occurs at
least once in a 30-day period and no more than once in a 7-day time.
PRODUCTION SUPPORT REQUIREMENTS
The system will send out a data report no less than once each 7-day period. Any errors in
the system will result in an immediate system report sent to the System Administrator
and/or the Station Manager.
SOFTWARE LICENSING REQUIREMENTS
No software licensing requirements are need as of 04/30/207
OPERATIONAL CONCEPTS
FUNCTIONALITY (BEHAVIORAL)
USE CASES
Author Janet Gatz
Date February 15, 2017
Version .05
Use-case name Public User Creates Account/Login Name (via website)
Use-case number 01
Page 12 of 35
Priority Unspecified
Source Unspecified
Primary business Public User

actor
Other participating WNIJ/WNIU Radio Station

actors
Interested WNIJ Station, Regional History Center/Northern Illinois

stakeholders University
Description Before a public user can search and stream audio items in the
system, they must create a login name.
1. Any person using the public interface would need to create

Typical course of
a login name before being able to search, access, and
events
stream audio data from the RDAR.
2. A listener would type in the URL or click on the link from
the WNIJ/WNIU website.
3. The main screen will appear asking for the user’s login ID
and password. There will be a link for patrons to either
receive a password reminder via E-mail, or to register and
create a new login.
4. The listener would then type their information.
A. Their first and last name [required]
B. Their E-Mail address [required]
C. Verify E-Mail address [required]
D. Login Name [required]
E. Which station they regularly listen to (WNIJ or WNIU)
[required, but will include options “I choose not to
answer” and ‘both’]
F. How long have they listened to the station [required,
Page 13 of 35
but will include third option, ‘I chose not to answer’.]

G. What shows do they normally listen to on the station.
[optional]
H. How do they listen to the station? (radio/online/app)
[optional]
I. Would they like updates about upcoming WNIU/WNIJ
events? (yes/no) [required]
J. Password [required]
K. Verify/repeat password [required]
5. Once all questions are answered, the listener will click on
the ‘Register now’ button.
6. The site will announce that an e-mail verification has been
sent.
7. The listener will click on the verification link in the email.
This will allow access to the public interface
Alternate courses Several of these steps can possibly be removed and become an
optional survey post-registration.
Conclusion The public user will have a secure log in to use while listening to
the WNIJ/WNIU backlog of audio files.
Post-condition A valid account has been created and the user can search for audio
from the application. The database will also have an updated and
valid password and e-mail address for the user.
Implementation This use case requires a valid e-mail to run.

constraints and
specifications
Assumptions Assumes the listener will have a valid e-mail account and can
access it through the world-wide web.
Page 14 of 35
1. Many listeners are older and may not have email. What can
Open issues
we do to ensure that they can still access this information?
2. How difficult will we require users to make their account
passwords.
3. Will the station put an open computer in WNIJ/WNIU’s lobby
for patrons to access who do not have an e-mail or computer?
4. Should staff have individual log in as well or a universal log in
for all employees?
Author Janet Gatz
Version .05
Use-case name Find a previously aired show/broadcast
Use-case number 02
Source Unspecified
Primary business Public patrons, Reporters/Producers, Community

actor Relations/Outreach

actors
Interested WNIU/WNIJ Station, Public patrons, Reporters/Producers,

stakeholders Community Relations/Outreach
Page 15 of 35
Description Both public and staff users can find a specific show or broadcast
through the browser
1. Listener will type in the URL or click the link on the

Typical course of
WNIJ/WNIU web page to get to the system and log in.
events
2. On the main menu, user will click on browse icon to open a
drop-down menu.
3. From the drop-down menu, the user will click on ‘browse by
show’. This will take the user to a page with an alphabetical
listing of all shows with available audio.
4. User will click on the show they are interested in.
5. The page will list all broadcast audios of the selected show
from newest on.
6. The user clicks on the desired week of the show. This will
take the user to a page containing any show information and
the audio file available for streaming.

Alternate courses
2. On the main menu, user will enter the name of the show in
the search menu.
3. Search results will return with a link to the show’s main audio
menu.
from newest on.
Conclusion At the end of this process, the user should be able to choose one
audio file to listen to from a list of audios from one particular
show.
Post-condition The system will have a record of what show/audio the user was
interested in.
Assumptions The user knows what show and session they are looking for.
Page 16 of 35
1. Many of the older shows may not be known by younger

Open issues
users or users new to the DeKalb area.
2. Some shows are from the 1960s and 1970s. They may
need to have information about content listed for those
who have not heard of them before.
Author Janet Gatz
Version .05
Use-case name Listen to show/broadcast
Use-case number 03
Source Unspecified
Primary business Public patrons, Reporters/Producers, Community

actor Relations/Outreach

actors
Interested WNIU/WNIJ Station, Public patrons, Reporters/Producers,

Page 17 of 35
Description Both public and staff users can stream the audio of a specific
broadcast once it has been found.

Typical course of
events
2. On the main menu, user will click on browse icon to open
a drop-down menu.
3. From the drop-down menu, the user will click on ‘browse
by show’. This will take the user to a page with an
alphabetical listing of all shows with available audio.
from newest on.
take the user to a page containing any show information
and the audio file available for streaming.
7. User clicks on the stream plug in to begin audio playback.

Alternate courses
2. On the main menu, user will enter the name of the show in
the search menu.
3. Search results will return with a link to the show’s main
audio menu.
from newest on.
take the user to a page containing any show information
and the audio file available for streaming.
6. User clicks on the stream plug in to start audio playback.
Conclusion The user will hear their chosen audio broadcast.
Post-condition The system will compile which audio files are accessed more.
This will help when looking at the interests for future community
relations events.
Implementation Requires users to have an internet connection. May experience

constraints and lag if connection is weak.
specifications
Page 18 of 35
Assumptions User is using either the application or has a computer with the
proper streaming plug ins installed.
1. The streaming service may suffer from lag issues

Open issues
depending on a user’s internet commotion.
2. Users may not be able to access files once if connection is
lost.
3. This will not help any users without internet.
Author Janet Gatz
Date March 05, 2017
Version .05
Use-case name Upload audio files
Use-case number 04
Source Unspecified
Primary business Reporters/Producers, Community Relations/Outreach

actor
Other participating WNIJ/WNIU Station, Station Manager

actors
Interested WNIJ/WNIU Station, Station Manager, Reporters/Producers,
Page 19 of 35
Description Staff/Reporters upload audio files to the system.
1. Staff will type in the URL or click the link on the WNIJ/WNIU
Typical course of
web page to get to the system and log in using their log in
events
information/staff log in.
2. On the main menu, staff member will click the ‘upload new
file/broadcast’ button.
3. A new screen will display a number of data entry boxes.
a. Title of the file [required]
b. Show file was featured on [required]
c. Subject of the file [required]
d. Creator of the file [required]
e. Date created [required]
f. Description of the subject matter/file [required]
g. Date Aired (approximate) [required]
4. The data is verified as a viable audio file.
5. When the file is validated, it will be stored in the database
with the status of IN PROCESS.
6. A message is displayed – Do you want to add digital audio
file to the system? Y/N
7. If the answer is no, the system will return to the data entry
page for editing/adding a new file.
8. If the answer is Y, the data is uploaded to the server.
9. Upon upload to the server, an E-mail is sent to the Station
manager acknowledging the upload.
Conclusion Members of the WNIU/WNIJ Staff will be able to upload audio

files of more recent broadcast.
Post-condition The station manager and/or web manager will receive notification
of a new file for station records.
1. The log in information for staff is still in flux.

Open issues
2. If staff have their own log in’s instead of a general
employee log in, then the ‘creator of file’ metadata may be
redundant.
Page 20 of 35
3. The e-mail to the station manager and/or web master may

be redundant due to the goal to compile data at the end of
the month.
Author Janet Gatz
Version .08
Use-case name Listen to raw interviews
Use-case number 05
Source Unspecified
Primary business WNIJ/WNIU Staff, Public

actor
Other participating WNIJ/WNIU station

actors
Interested WNIJ/WNIU Station, Station Manager, Reporters/Producers, NIU,

stakeholders Regional History Center, Public
Description Both public and staff users can stream the audio of a specific
‘raw’ interview. A ‘raw’ interview is the audio from before it is
edited into a broadcast story.
Page 21 of 35
1. Public/Staff will type in the URL or click the link on the

Typical course of
events
drop-down menu.
3. From the drop-down menu, the user will click on ‘raw
interviews’. This will take the user to a page with an
alphabetical listing of all interviews by interviewee.
from newest on.
1. Public/Staff will type in the URL or click the link on the

Alternate courses
2. On the main menu, user will click on the search engine.
3. Using the search engine, the user will type the name of the
interviewee or interviewer, then press search or hit the enter
key.
4. The results page will list all audio files with those results.
5. To the left of the results, the user will click on a ‘filter’ menu.
6. From the filter menu, the user will click on ‘raw audio only’.
7. The results page will not only show audio files with the tag
‘raw audio’.
8. The user clicks on the desired file. This will take the user to a
page containing information about the file, the date it was
recorded, the subject, and the interviewer.
Conclusion The listener is now able to listen to the unedited audio file.
1. Need to make sure that the raw interview audio does not
Open issues
have any copyright infringements.
2. Get permissions from original staff who conducted interview if
possible.
Page 22 of 35
Author Janet Gatz
Version .05
Use-case name Download audio files
Use-case number 06
Source Unspecified
1. Staff member will type in the URL or click the link on the
Typical course of
WNIJ/WNIU web page to get to the system and log in under
events
the appropriate staff login and password.
drop-down menu.
3. From the drop-down menu, the user will click on ‘raw
interviews’ or browse by show. This will take the staff
member to the appropriate sub-menu.
4. Staff member will click on the show/raw interview they are
interested in.
from newest on. If they are looking in raw interviews, the
page will list those files by most recent.
6. The staff member clicks on the file they are looking for.
7. Once the staff member is in the audio file’s main screen,
there will be a ‘download’ button listed. The staff member
can either left click this button to download to the computer’s
default folder, or right click on it to save the file in a different
area of the computer.
8. Once the file is downloaded, the system will send a ticket to
the Station manager for auditing purposes.
1. Staff member will type in the URL or click the link on the
Alternate courses
WNIJ/WNIU web page to get to the system and log in under
Page 23 of 35
the appropriate staff login and password.

2. On the main menu, user will click on the search engine and
type the subject they need audio for.
3. The results page will show all files that have tags that meet
the criteria of the staff member’s search.
4. The staff member clicks on the file they are looking for.
5. Once the staff member is in the audio file’s main screen,
there will be a ‘download’ button listed. The staff member
can either left click this button to download to the computer’s
default folder, or right click on it to save the file in a different
area of the computer.
6. Once the file is downloaded, the system will send a ticket to
the Station manager for auditing purposes.
Conclusion The staff member will now have a copy of the file to edit and
splice for future work.
1. I don’t know how often this will be needed.

Open issues
Author Janet Gatz
Version .05
Use-case name Monthly data assessment
Use-case number 07
Source Unspecified
Primary business Community Relations/Outreach, Station Manager
Page 24 of 35
actor
Other participating WNIJ/WNIU Station

actors
Interested Station Manager, WNIJ/WNIU Station, Community

stakeholders Relations/Outreach
Description A monthly accounting of all transactions that take place in the

RDAR system.
1. The system automatically logs all user log ins, searches, and
Typical course of
audio streams, along with staff uploads and downloads.
events
2. When each download or file upload occurs, the Station
Manager (or appropriate position) is notified via e-mail.
3. At the end of the month, all user data is correlated into a
report and sent to the Station Manager.
4. At the end of the month, all public user data is correlated into
a report and sent to Community Relations/Outreach.
Conclusion Data from the system is compiled and sent to the appropriate
members of staff. This data can then be used to assist in
fundraising (Community Relations/Outreach) and to assess staff
use (Station Manager)
Open issues How do we make sure the reports are being sent to the correct
people?
Is there a way to edit this information due to turnover?
DATA MODELS
Page 25 of 35
System Architecture Model
Page 26 of 35
Upload Audio Model
Page 27 of 35
Listen to Raw Audio Model
Assessment Report Model

Page 28 of 35
Page 29 of 35
USER INTERFACE PROTOTYPES

Main Menu-Prototype.
Page 30 of 35
Search Results Menu Prototype
Page 31 of 35
Individual Audio Streaming Page
Page 32 of 35
Sign Up Screen
Page 33 of 35
Log in Screen
REQUIREMENT CONSTRAINTS & DEPENDENCIES
DESIGN CONSTRAINT
ID Constraint
C.1.1 System must have a straightforward design.
C.1.2 Must be able to be accessed and used on most computer and mobile
systems.
PROJECT CONSTRAINT
ID Constraint
C.2.1 Illinois has not had a budget in 2 years. WNIJ is affiliated with a
state-run institution (Norhtern Illinois University).
C.2.2 The board wants the system complete before the next pledge drive
(6 months)
C.2.3 Audio files are in a variety of formats
Page 34 of 35
C.2.4. Most of the data in the current catalog is based on the case
information. Do not know if that information is correct
REFERENCE MATERIAL
Use this table to consolidate all reference documents, their filenames, and their location.
Description Filename and Version Location

Requirements Trace Process Model_Gatz C://Desktop/School/754/Assi
Document (version 1.0) gnments
Use Cases (Business Use_Case_Gatz (version C://Desktop/School/754/Assi
Requirements 1.0) gnments
Document)
System Architecture System_Archetecture_Gatz C://Desktop/School/754/Assi
Document (Version 1.2) gnments
Security Access Security_Access_Gatz C://Desktop/School/754/Assi
(Version 1.2) gnments
Assessment Report Monthly Assessment Report C://Desktop/School/754/Assi
Document gnments
Interface Design Interface Design_Gatz C://Desktop/School/754/Assi
Document gnments
System Thinking System_Thinking_Proposal C://Desktop/School/754/Assi
Document (version 1.0) gnments
Use Case Use_case_Gatz (version C://Desktop/School/754/Assi
13.0) gnments
ACRONYMS AND GLOSSARY

RDAR: Radio Digital Audio Repository
NIRIS: The Northern Illinois Radio Information Service. This is the Northern Illinois
University public broadcasting service and is used as a supplement to the Library of
Congress Talking book program.
OS: Operating System
Page 35 of 35

754 Sys Req Spec Final Gatz

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

754 Sys Req Spec Final Gatz

Încărcat de

Drepturi de autor:

Formate disponibile

RADIO DIGITAL ARCHIVE REPOSITORY

SYSTEM REQUIREMENTS SPECIFICATIONS

BUSINESS OWNER - WNIJ/WNIU RADIO]

PROJECT MANAGER – JANET GATZ

ORIGINAL PLAN DATE: JANUARY 18, 2017

REVISION DATE: APRIL 30, 2017

REVISION HISTORY ............................................................................................................................................. 2

TABLE OF CONTENTS .......................................................................................................................................... 3

FUNCTIONAL REQUIREMENTS ............................................................................................................................ 7

FUNCTIONALITY (BEHAVIORAL) ....................................................................................................................................... 12

ACRONYMS AND GLOSSARY .............................................................................................................................. 35

PURPOSE OF THIS DOCUMENT

GOALS OF THE PROJECT

CLIENT, CUSTOMER AND OTHER STAKEHOLDERS

USERS OF THE PRODUCT

ASSUMPTIONS AND OTHER RELEVANT FACTS

USER INTERFACE REQUIREMENTS

Author Janet Gatz

Date February 15, 2017

Use-case name Public User Creates Account/Login Name (via website)

Primary business Public User

Other participating WNIJ/WNIU Radio Station

Interested WNIJ Station, Regional History Center/Northern Illinois

1. Any person using the public interface would need to create

but will include third option, ‘I chose not to answer’.]

Implementation This use case requires a valid e-mail to run.

Author Janet Gatz

Date February 18, 2017

Use-case name Find a previously aired show/broadcast

Primary business Public patrons, Reporters/Producers, Community

Other participating WNIJ/WNIU Radio Station

Interested WNIU/WNIJ Station, Public patrons, Reporters/Producers,

1. Listener will type in the URL or click the link on the

1. Listener will type in the URL or click the link on the

1. Many of the older shows may not be known by younger

Author Janet Gatz

Date February 28, 2017

Use-case name Listen to show/broadcast

Primary business Public patrons, Reporters/Producers, Community

Other participating WNIJ/WNIU Radio Station

Interested WNIU/WNIJ Station, Public patrons, Reporters/Producers,

1. Listener will type in the URL or click the link on the

1. Listener will type in the URL or click the link on the

Conclusion The user will hear their chosen audio broadcast.

Implementation Requires users to have an internet connection. May experience

1. The streaming service may suffer from lag issues

Author Janet Gatz

Date March 05, 2017

Use-case name Upload audio files

Primary business Reporters/Producers, Community Relations/Outreach

Other participating WNIJ/WNIU Station, Station Manager

Interested WNIJ/WNIU Station, Station Manager, Reporters/Producers,

stakeholders Community Relations/Outreach

Description Staff/Reporters upload audio files to the system.

Conclusion Members of the WNIU/WNIJ Staff will be able to upload audio

1. The log in information for staff is still in flux.

3. The e-mail to the station manager and/or web master may

Author Janet Gatz

Date February 20, 2017

Use-case name Listen to raw interviews

Primary business WNIJ/WNIU Staff, Public

Other participating WNIJ/WNIU station

Interested WNIJ/WNIU Station, Station Manager, Reporters/Producers, NIU,