SpEAK:Spring 2012 RAD


 * Home
 * Semesters
 * Spring 2012
 * Documents
 * [Requirements and Analysis Document]

=Introduction= The SpEAK database subsystem will manage speech experiment data. Once completed, the SpEAk back-end database will give its users the power to store, manage, and deliver important speech research information.

There are three types of users who will interact with the database subsystem: viewer, author, and administrator. Each user will have defined permissions to how they interact with the system. A viewer may view experiments, an author will add, edit, and delete their own experiments, and the administrator will have to ability to add, edit, delete, and create new users.

The database subsystem will be operating on the MySQL database management system. MySQL runs as a server application that provides multi-user access to a number of databases. Client utilities, such as mysql, mysqladmin, mysqldump, and others are used to create, query, and administer databases in the MySQL system. The database is written in the Structured Query Language (SQL). MySQL runs on virtually all platforms, including Linux, UNIX, and Windows.

The Speech Project at the UNHM has the extremely complex task of designing speech recognition software. Implementing this software requires performing hundreds of tedious experiments to record sounds and other information needed for its development. Currently the Speech program has no easy way of storing and organizing these performed experiments for future use.

Currently the Speech program has no easy way of storing and organizing these performed experiments for future use.

The project scope is to deliver a working prototype database conforming to the project specifications.

The Speech Lab team is developing a database in the MySQL programming language for Capstone to store and run the queries on their experiments they so desperately need.

Results of the SpEAK project will incorporate an operational database capable of installing itself onto the user's machine via a script file, and an online wiki site describing the process of development.

Client Profile
The client for the SpEAK project is the Capstone team heading the Speech Project at UNHM. They have the extremely complex task of designing speech recognition software. Some of their tasks are to perform experiments to record sounds and other information needed for the development of Speech.

Purpose of the system
The SpEAK system's purpose is to store, manage, and deliver speech research information created from speech experiments.

Objectives and success criteria of the project
The objective of this semesters SpEAK project is to implement a working prototype of the SpEAK back end database and its front end GUI. The back end should allow for new data storage, editing of existing stored data, deleting of stored data, and attaching additional files to existing experiment entries. The front end GUI should allow for the creation of a new user login by the administrator, a user viewer to view existing experiments, and for an author type user to create new experiments, edited their own existing experiments, and view their experiments.

Definitions, acronyms, and abbreviations

 * SpEAK - Stands for Speech Experiment Accessible Knowledge is a project to develop an online database for accessing knowledge acquired during experimentation in speech research.

Overview
There are three types of users for the system: a viewer, an author, and an administrator. The viewer will be able to view any experiment. The author will be able to view any experiment, create new experiments, and will be able to edit their own experiments. The administrator user will be able to view any experiment, create new experiments, edit any experiment, delete any experiment, create new users, and delete existing users.

The front end GUI interface will be used for user interaction. It consists of; a login page, which prompts for a user name and password, a view page, which displays the experiment number, title, date created, modified date, and the author of the experiment, a new experiment page, which prompts data entry for the author, description, and will allow the author to upload file attachments. The remaining page is the admin page and this area is where the administrator will be able to create new user logins and assign user access control.

The back end of the system is written in the structured query language (SQL) and the database management system (DBMS) will be MySQL. MySQL runs as a server application that provides multi-user access to to the database and client utilities, such as MySQL, MySQLDump, MySQLAdmin will be used to manage the database directly. The database is supported on multiple platforms, including Linux, UNIX, and Windows.

=Current system=
 * As of January 2012, there was no complete system in place.

=Proposed system=

Target Environment

 * Interaction between system & environment independent of environment
 * The database subsystem will be operating on the MySQL database management system. MySQL runs as a server application that provides multi-user access to a number of databases. Client utilities, such as mysql, mysqladmin, mysqldump, and others are used to create, query, and administer databases in the MySQL system. The database is written in the Structured Query Language (SQL). MySQL runs on virtually all platforms, including Linux, UNIX, and Windows.

Usability

 * Describes user interface / documents

Reliability

 * Describes time between failure

Performance

 * Describes quantifiable attributes of system
 * response time
 * throughput
 * availability

Supportability

 * Ease of changes to system
 * adaptability
 * maintainability
 * protability

Implementation

 * What tools you will use? Hardware/Software

Interface

 * Constraints on external systems, legacy, interchange formats

Scenarios / Use Case Models


ACTOR Tasks: Viewer, Author, Administrator
 * Viewer Use Case Scenarios:
 * 01.View all experiments
 * 02.Cannot edit or delete experiments
 * 03. Cannot create experiments


 * Author Use Case Scenarios:
 * 04. Can view all experiments
 * 05. Can create experiment
 * 06. Can edit the experiments they have created
 * 07. Cannot edit other users’ experiments
 * 08. Can delete their own experiments
 * 09. Cannot delete other users’ experiments


 * Administrator Use Case Scenarios:
 * 10. Can view all experiments
 * 11. Can create an experiment
 * 12. Can edit any experiment
 * 13. Can delete and experiment

GUI Tasks: View, New, User, Admin
 * GUI View Use Case Scenarios:
 * 14. Experiment# (Auto generated)
 * 15. Experiment title
 * 16. Date created
 * 17. Date modified
 * 18. Authors


 * GUI New Use Case Scenarios:
 * 19. Experiment# (Auto generated)
 * 20. Authors
 * 21. Create date
 * 22. Last modified date
 * 23. Description
 * 24. Attachments
 * 25. Save button (front end)


 * GUI User Use Case Scenarios:
 * 26. View login page
 * 27. Enter user name
 * 28. Enter password
 * 29. Login


 * GUI Admin Use Case Scenarios:
 * 30. Verify concurrent user login to database
 * 31. Webpage accessible to anyone to view experiments
 * 32. Verify permissions for existing experiments
 * A. Anyone can see experiments
 * B. Only team members can see experiments
 * C. Admin level, administrators can add team members

Object model
Textual definitions with class diagrams illustrating object relationship including all identified objects, their attributes, and in sequence diagrams their operations
 * a. Data dictionary
 * b. Class diagrams

Dynamic Model

 * The behavior of the object model in terms of state machine diagrams and sequence diagrams including use cases involving many actors

User interface—navigational paths and screen mock-ups
=Glossary=