Updated Jul 24, 2007 by uhuraproject
Labels:	Phase-Requirements

Requirements

The Uhura Requirements specify non technical design.

Introduction

Before getting into development the requirements of Uhura have to be defined. This is not focused on technical details, but more on features.

Requirement phase is finished

Details

Having a free alternative for efficient language learning on desktop computers.

The requirements describe in detail what Uhura is supposed to do from the user perspective, without technical details about the implementation.

The Uhura software client is the interface for users to have a language lessons.
Users can load courses from the file system, and import them.
The client manages the list of imported courses.
The client manages browsing the course(s) for a lesson.
The structure of a course is user defined.
The client manages different user accounts for students.
A created student account has a profile, and contains information about learning results.
Users can optionally select volume, feedback sound & graphics, and text size.
A lesson groups lesson elements in tabs
The structure of a lesson is user defined.
The elements of a lesson are loaded as plug-ins into the client
Loaded elements represent the available functions of a lesson.
Lesson elements may modify the active user profile and save statistics.
Users can optionally decorate a lesson element as test, with delay, and timer.
In short: Rosetta Stone exercise plug-ins
Separation of global and local lesson data

The Uhura client is not time critical, but plug-ins may be.
User data will be encrypted.
Not responsible for remote holes in plug-ins, though this should be avoided.
Client runs also on old computers, as Pentium II/III.
While the client is small, the amount of data is unpredictable.
Flexible management of elements in a lesson.
Flexible structure for language courses.
Expandable user profile.
Independent statistics of course, lessons, and elements for a user.
Extend functionality of a lesson by plug-ins
Possible integration of internet communication technology in a later state.
With a stable release of the client, focus of development switches to course design and plug-ins. If course design isn't possible the project failed, and also due to lack of motivation.

Ideally, the requirements are understandable for users, without technical details.
Ideally, the requirements are detailed enough to clarify the problem, and give developers sufficient information to individually work out the problems, without specifying a solution.
Ideally, the requirements doesn't conflict.
Ideally, the requirements prioritize, to easily solve trade-offs and conflicts for the implementation.
Ideally, each requirement element is testable.
Ideally, all possible changes in the requirement are specified.

Ideally, the requirements for the software client are complete and realizable.
Incomplete requirements for the language courses. This is done after the client is stable.
Incomplete requirements for the integration of internet technologies. Though there is no concrete concept, this should always be at the back of the developers mind.