System/Segment Specifications
of the eQip project

This section describes the system characteristic requirements.

1. Functions
   1. User training

      In addition to providing a user manual, the system shall also allow the users to train themselves.

      1. Welcome

         REQ.1.1.1.1	First Boot	When the system is initially booted by the end user, it shall provide the user with a tool to discover the basics of the system's User Interface.
         REQ.1.1.1.2	Basics Settings	While the user gets familiar with the GUI, the system shall provides him/her with a way of entering the basic settings, such as : touch-screen calibration owner information date, time and location

      2. Help

         REQ.1.1.2.1	System Help	Upon a user's request, the system shall provide the user with a complete documentation stating the uses of the system.

      3. Pen input training

         REQ.1.1.3.1	Pen Game	The system shall provide the user with an entertaining way of learning the pen input stroke.
         REQ.1.1.3.2	Stroke References	When the user is entering data with the pen, the system shall provide a Stroke Reference Guide upon user's request.

   2. Personal Information Manager

      The system shall provide the user with tools to manage his/her agenda, contact and notes.

      1. Pocket Diary

         REQ.1.2.1.1	Diary display	The user shall be able to change the way in which the events are displayed in the Pocket diary: show a day show a week show a month show a year show the all the todo show today events and due todo The user shall have the ability to display the events that are filled in a given folder.
         REQ.1.2.1.2	Diary event	The user shall be able to create an event out of the following type of events: Meeting The default data of such an event are : date/time (and periodicity) starting/ending time notification (show a warning X days/hours/minutes before event) subject category (work/fun ...) list of folders where the event is filled in list of actions to perform participants (link to contact cards) location (possible link to a contact card) comments link to related notes / files user specific fields ... Example : "Project review" meeting at 4:00pm (duration 1 hour) Appointment The default data of such an event are : date/time (and periodicity) starting/ending time notification (show a warning X days/hours/minutes before event) subject category (work/fun ...) list of folders where the event is filled in list of actions to perform contact (link to contact card) location (possible link to a contact card) comments link to related notes / files user specific fields ... Example : Doctor McCoy at 6pm Activity The default data of such an event are : date/time (and periodicity) starting/ending time notification (show a warning X days/hours/minutes before event) subject category (work/fun ...) list of folders where the event is filled in list of actions to perform contact (possible link to contact card) location (possible link to a contact card) comments link to related notes / files user specific fields ... Example : Going for a run at 3pm To do The default data of such an event are : status (done/in progress/not done) subject list of folders where the event is filled in date/time due (and periodicity) notification (show an warning X days/hours/minutes before the event) contact (link to contact card) comments link to related notes / files user specific fields ... Example : Confirm meeting with John Do Reminder The default data of such an event are : date (and periodicity) notice (show an warning X days before the event) subject comments list of folders where the event is filled in link to related notes / files / contact user specific fields ... Example : Bob b-day ! Action The default data of such an event are : date/time (and periodicity) subject list of folders where the event is filled in type (execute,send data) action data comments link to related notes / files Example : Every morning at 5am, get online and grab my favorite web pages Period The default data of such an event are : start date/time, end date/time subject list of the event's categories that should be disabled during the period list of folders where the event is filled in comments link to related notes / files Example : During my vacation, disable any work related events (like periodic meetings).
         REQ.1.2.1.3	Diary event filling	When the user creates a new event, or modifies an existing event, the user should be given the choice of which folder to place it.
         REQ.1.2.1.4	Diary event deletion	The user shall be allow to delete all events older than a given date, or to delete one or several selected events. When deleting a recurrent event, the user shall be asked if only the current occurence should be removed of all further occurences.
         REQ.1.2.1.5	Diary event action	For most of the events, a list of actions can be specified by the user. When the event occurs, the actions will be performed. The action can be : start a given application show the note application and create a new note (of a given type) display a given note list a given folder
         REQ.1.2.1.6	Diary event periodicity	When specifying the periodicity of an event, the user shall have the following choices: every day every other day every X days every week every other week every X weeks every month every other month every X months same week each month every year every other year every X years same week each year
         REQ.1.2.1.7	Diary event notification	When an event is scheduled to start, the system shall show a notification slip that informs the owner that the given event is about to start. Depending on the settings for the event, the notification can happen before the event itself. When the slip is shown, the user can snooze or discard the notification. When snoozed, the slip and any accompanying sounds will be shown to the user at a later time (specified when snoozed).
         REQ.1.2.1.8	Diary settings	The user shall be allow to modify the following settings of the Diary: first day of the week, working days daily opening hours default event's notification
         REQ.1.2.1.9	Diary export	On an user's request, the contents of the Diary shall be exported in XML or HTML file.
         REQ.1.2.1.10	Diary services	The system shall provides to any applications, the ability to create/edit/read/delete events.
         REQ.1.2.1.11	Event sending	The system shall allow the user to send an event through any communication medium available on the system.
         REQ.1.2.1.12	Holidays	The system shall allow the installation on a device of a special add-on, listing all the holidays for a given country. Holidays should be marked in the calendar.
         REQ.1.2.1.13	Counting days	The system shall provide the user with an easy way to count days (or only working days) between two given dates.

      2. Contacts

         REQ.1.2.2.1	Contact display	The system shall allow the user to create view profiles, by selecting the field to display in a given profile. The user will be able to switch between profiles easily.
         REQ.1.2.2.2	Contact handling	The system shall allow the user to create/delete/modify contacts and to place them in folders.
         REQ.1.2.2.3	Contact list	The system shall allow the user to list the contacts by folders and by any contact field.
         REQ.1.2.2.4	Contact data	There are three kinds of contact entries that the user can create: Human Being title name first name nickname keywords (list of like/dislike words...) special day (list of special event (date/subject) (diary events can be generated according)) list of related people with their relation (ex: assistant , Ms Doe) photo(s) (if available) location (home/work, link ) company (link to another contact card) position phone (home/work/cell) fax (home/work) email web site comments notes (link to notes related to this contact) diary (link to events related to this contact) files (link to related files/folders to this contact) Entity name logo (if available) keywords (list of field/activity words...) contacts (list of contacts in the compagny, possible link to another contact card) location (link) phone (home/work/cell) fax (home/work) email web site comments notes (link to notes related to this contact) diary (link to events related to this contact) files (link to related files/folders to this contact) Location nick name (if any. ex: home , work ...) address how to get there comments contacts (link to contact related to this location) notes (link to notes related to this location) diary (link to events related to this location) files (link to related files/folders to this contact)
         REQ.1.2.2.5	Contact user's field	The system shall allow the user to add his/her own fields to a contact entry.
         REQ.1.2.2.6	Contact export/import	The system shall support the export or import of a contact to/from a XML, HTML or vCard format.
         REQ.1.2.2.7	Contact services	The system shall provide any application with the ability to create/edit/read/delete contacts.
         REQ.1.2.2.8	Entry sending	The system shall allow the user to send an entry through any communication medium available on the system.

      3. Notepad

         REQ.1.2.3.1	Notes handling	The system shall allow the user to create or modify notes and place them in one or more folders.
         REQ.1.2.3.2	Notes display	The user shall be able to display a list of the notes, sorted by folder and/or by title or type.
         REQ.1.2.3.3	Notes contents	All notes on the system shall have the following attributes: creation date modification date title protection (read/write) type (paper roll type) list of folders in which the note was placed list of contact links list of diary links list of file links list of note links (note can be linked to other notes)
         REQ.1.2.3.4	Notes standard paper roll	The system shall support the following paper roll: Paper note (standard text note) Blank paper (basic handfree drawing) Named note (specifically linked to a contact) Graph paper (precise drawing) To do checklist (various styles possible, with time tracking and priority) Shopping checklist Two columns (allowing simple math operation) Drawing canvas (complex handfree drawing) Meeting note Phone conversation form Personal Diary Daily activities (with time tracking) Email Direction (to a given location) Music partition Audio recording Ruby listing
         REQ.1.2.3.5	Notes add-ons	The system shall support the addition of third-party paper roll add-ons.
         REQ.1.2.3.6	Notes export	The user shall be able to export the notes in XML and HTML.
         REQ.1.2.3.7	Notes services	The system shall provide any application with the ability to create/edit/read/delete notes.
         REQ.1.2.3.8	Notes sending	The system shall allow the user to send a note through any communication medium available on the system.

   3. World-connected

      It is now expected that an information appliance be connected to the internet or to a local network.

      1. Communication medium

         REQ.1.3.1.1	Network card	The system shall support communication over a LAN network card.
         REQ.1.3.1.2	Wireless card	The system shall support communication over a wireless network card.
         REQ.1.3.1.3	Serial link	The system shall support communication over a serial link.
         REQ.1.3.1.4	USB link	The system shall support communication over an USB link.
         REQ.1.3.1.5	IR link	The system shall support communication over an infrared link.

      2. Communication protocol

         REQ.1.3.2.1	TCP/IP	The system shall fully support the TCP/IP protocol over any of the mediums.
         REQ.1.3.2.2	Internet access	The system shall support Internet access using PPP,PPPOE or direct ethernet connections.

      3. Device/Host connection

         When the device is connected to a host computer, one of the three following modes can be selected by the user :

         REQ.1.3.3.1	Slave mode	In this mode, the device is seen as an external disk by the host computer. Users can treat the device FS like any FS (respecting the file's rights and the autorisation given by the owner to the host computer). Applications on the device can be started and will be displayed on the host screen. The keyboard and mouse will be used for this.
         REQ.1.3.3.2	Master mode	In this mode, the device acts as the owner of the screen, keyboard, and mouse of the host computer. The screen becomes a copy of the device screen but with far more realestate. Applications started on the device are displayed on the host screen. The host computer is seen as an external disk by the device. Users can treat the host FS as they will do on any FS ( respecting the file's rights). eQip applications installed on the host computer are added in the Launcher in a "Host" folder. When the device is disconnected from the host, the host resume its "normal" screen contents and behavior.
         REQ.1.3.3.3	Relay mode	In this mode, the host computer acts as an INTERNET access point, providing an ethernet link over the connection. The host computer is seen as computer on the network and can be contacted and used with standard ethernet applications.

      4. Device/Device connection

         REQ.1.3.4.1	On-the-fly Network	The system shall allow for two or more devices to establish a network through any communication medium. Once a device has join such a group, it can share its FS (all or part of it) and its application, with the other members. Applications installed on one device but missing from the others, are added in the Launcher in a "Remote" folder. A device's user can run these applications, displayed on the his/her device. Depending on the application launch setting, the application will run on the owner's device or on the remote device. In order to be "shared" an application should be marked by the owner of the device as shareable. By default, a "shared" application is always set as "execute" on the user's device.

      5. E-mail and Instant messanger

         REQ.1.3.5.1	Email	The system shall allow the user to receive, send, and store e-mails.
         REQ.1.3.5.2	Emailing	The system shall allow every application running on it to send or read email.
         REQ.1.3.5.3	POP and SMTP account	The system shall be able to download email from a POP account and use a SMTP server to send outgoing emails.
         REQ.1.3.5.4	Instant messanger	The system shall provide the user with a popular Instant Messanger application.

      6. Web surfing

         REQ.1.3.6.1	Browser	The system shall provide a way of browsing HTML documents.
         REQ.1.3.6.2	Offline reading	The system shall allow the user to download website contents for offline reading.
         REQ.1.3.6.3	Web cache	The system shall cache documents in only RAM during HTML viewing

      7. Services providing

         REQ.1.3.7.1	Remote access	The system shall provide a way of performing remote access to the device, through any of the supported mediums or protocols.
         REQ.1.3.7.2	FTP server	The system shall allow the device to provide an FTP access through the TCP/IP protocol. This should not be enabled by default.

      8. Data stream sending/reception

         REQ.1.3.8.1	Data stream	The system shall process data received from a communication medium as a Stream. It should associate each stream with a Mime-Type that identifies the type of the stream.
         REQ.1.3.8.2	Stream repository	The system shall keep the data stream received or these to be sent (in a special repository), when using a non real-time communication.
         REQ.1.3.8.3	Stream processing	The system shall allow an application to monitor the stream repository for processing. It allow the application to decide whether or not a stream shall be removed from the repository once it is processed.
         REQ.1.3.8.4	Register to stream	The system shall allow an application to register itself to process a given type of stream. The system shall call this application whenever a stream of this type is placed in the repository.

   4. Pocket entertainment

      The system should provide the user with some entertaining applications.

      1. MP3 Player

         REQ.1.4.1.1	Playing MP3	The system shall allow the user to play MP3 files from a playlist stored in any known location.
         REQ.1.4.1.2	Sound level tuning	When playing MP3 files, the system shall allow the user to fine tune the level of the sound.
         REQ.1.4.1.3	MP3 Tag	The system shall display the TAG of the MP3 file and allow the user to edit , or create a new TAG.
         REQ.1.4.1.4	Screen off	The system shall allow the user to turn the screen of the device OFF when playing a MP3 in order to conserve energy.
         REQ.1.4.1.5	MP3 file vanishing	The system shall support the deletion of MP3 files present in the playlist.
         REQ.1.4.1.6	Playlists	The system shall allow the user to store several playlists and select which one to play/modify/delete.
         REQ.1.4.1.7	Running mode	The system shall allow this application to run as a stand-alone application, or as application embedded in the bottom bar.
         REQ.1.4.1.8	Playing controls	The user shall have the following controls when playing: play/stop pause fast forward/backward skip
         REQ.1.4.1.9	Control by gesture	The system shall provide the user with the ability to use the application in a gesture mode. This is when the screen becomes sensitive to gestures the user will make, in order to control the MP3 while the user is in motion and cannot see the screen.

      2. Movie Player

         REQ.1.4.2.1	Playing movies	The system shall allow the user to play movies stored in any location known by it.
         REQ.1.4.2.2	Movie formats	The system shall support the following movie format : MPEG DIVX
         REQ.1.4.2.3	Movie controls	The user shall have the following controls over the movie: play/Stop pause fast forward/backward frame by frame

      3. Games

         REQ.1.4.3.1	SDL library	The system shall provide the SDL library.
         REQ.1.4.3.2	Allegro library	The system shall provide the Allegro library.

   5. Operating Environment

      This section defines the software environment in which the user is in.

      1. Screen real-estate

         REQ.1.5.1.1	Screen division	The system shall divide the screen into three distinct parts: a bar on top of the screen a bar on the bottom of the screen a display area in between The purpose of the two bars is to display critical information for the owner and to give easy access to common features on the device, while the application area displays the currently running application.
         REQ.1.5.1.2	Bars hidden	The system shall allow at any time the user to hide the bars either completely or partially.
         REQ.1.5.1.3	Bars auto-hide	The system shall allow the bars to show themselves when the user tap on the hidden bar, and to hide again after a given delay. On special event, it shall be possible to the bars to show themselves.

      2. Top bar

         REQ.1.5.2.1	Application title	The bar shall display the name of the application running up-front.
         REQ.1.5.2.2	Application menu	When the user taps on the application title, it shall display a menu provided by the application.
         REQ.1.5.2.3	Top actions	The top bar shall allow the user to perform the following actions: rotate screen hide top and bottom bar close current application cycle through running application get help related to up-front application

      3. Bottom bar

         REQ.1.5.3.1	Client application	The bar shall allow an application to install actions and displays while running.
         REQ.1.5.3.2	Bar plugin	The bar shall accept special applications that are only running inside of it. This kind of application is called a Plug-In. Plugins raise the functionality of the bar, giving the user the complete choice of which Plug-in to run.
         REQ.1.5.3.3	Standard plug-ins	The device shall provide the following plug-ins : battery status This must show the estimated time of use left before the battery expires if the current load is maintained. time/date volume level (can be changed) screen brightness memory available (RAM/FLASH) CPU activity ticker (stock market style) turn backlight on/off list/switch running application pen input area for launching actions disable any future alarms (to be used in the event where the device goes stealth, whenever the alarm is going to be raised) list of applications installed on the device (grouped by folder) stopwatch (start/stop/pause/reset) emergency data such as: police phone number firefighter phone number family doctor phone number of person to contact (eg. spouse) depending on the current location (eg. these numbers would be different for different countries)

      4. Display area

         REQ.1.5.4.1	Area content	The system shall use this area to display the application. Applications are always occupying the whole area.
         REQ.1.5.4.2	Application maximized	The system shall increase the size of the display area when the bars are hidden and decrease the size when the bars are visible.

      5. Application launcher

         REQ.1.5.5.1	Application selection	The system shall provide the user a way to select the running application and sort them by filling folder and/or by storage location.
         REQ.1.5.5.2	Application filling	The system shall allow the user to fill installed applications in categories other than the one specified by the author.
         REQ.1.5.5.3	Application folder	The system shall allow the user to create or rename folders in which to move applications in.
         REQ.1.5.5.4	Application cross-filling	The system shall allow the user to fill an application in many folders.
         REQ.1.5.5.5	Recently used applications	The system shall display a list of the recently used applications.
         REQ.1.5.5.6	Most used applications	The system shall display a list of the applications that were most often used by the user.
         REQ.1.5.5.7	Favorites applications	The system shall allow the user to fill an application in a Favorites folder.
         REQ.1.5.5.8	Application's location	The system shall handle the situation when an application can be stored on a SD/PcCard/CF or inserted/removed by the user.
         REQ.1.5.5.9	Application list display	The system shall allow the user to display the installed application on the device in any of the following modes : large application icon and name small application icon and name application detailed infos location (store) size (exe/libs/data...) author/version/release date/installation date battery/memory usage stats frequency of use (once a day, every hour ...)
         REQ.1.5.5.10	User's name	The system shall allow the user to display its name in the launcher. A tap on the name shall display his/her business card.

      6. Backdrop

         The backdrop is the application shown on the system when no other application is running. This application cannot be closed even though other applications are running.

         REQ.1.5.6.1	Default backdrop	The system shall set the launcher application as the default backdrop.
         REQ.1.5.6.2	Application as backdrop	The system shall allow the user to select an application to be set as the backdrop.
         REQ.1.5.6.3	Backdrop switch	The launcher application shall allow the user to select the backdrop application. It shall also allow the user to reset the launcher application as the backdrop.

      7. Extra applications

         REQ.1.5.7.1	3rd-party applications	The system shall allow the user to install and use applications written by a 3rd-party.
         REQ.1.5.7.2	Software registration key	The system shall provide any application the possibility of using a software registration mechanism for shareware and a commercial 3rd party application.
         REQ.1.5.7.3	SDK	The system shall be shipped with a "Software Development Kit" so that a developer is able to develop and test an application on a host computer.

   6. Pocket computing

      The system shall provide the user several applications to fullfill his/her everyday needs.

      1. Assistant

         REQ.1.6.1.1	Assistant input	The system shall provide the user a simple way to request or find information and receive help or files located on the device.
         REQ.1.6.1.2	Find	The system shall be able to locate and return links to the items found from: applications files contacts diary events notes
         REQ.1.6.1.3	How-to	The system shall provide the user help related to the keywords entered by him/her.
         REQ.1.6.1.4	Application help	The user shall be allow to select an installed application and then be able to consult its documentation.

      2. File Browser/

         REQ.1.6.2.1	Browsing files	The system shall provide a way for the user to browse and manage the files stored on his/her device, and to navigate through the folders. The user shall be allow to move or copy files across storage devices.
         REQ.1.6.2.2	Content display mode	The system shall allow the user to display the contents of a folder in the following ways: large icon small icon detailed information
         REQ.1.6.2.3	Contents listing	The system shall allow the user to list the contents of a folder by sorting it according to any of the detailed information displayed. When no detailed information is shown, the contents is sorted by alphabetic order using their file names.
         REQ.1.6.2.4	File's icon	For every file, the system shall display an icon corresponding to the mime-type of the file.
         REQ.1.6.2.5	Mime-type	The system shall allow the user to create or modify a mime-type, and to set and change the icon.
         REQ.1.6.2.6	File's mime-type	The system shall allow the user to set or change the mime-type of a file and the application that handles the file.
         REQ.1.6.2.7	Preferred application	The system shall allow the user to set or change the preferred application for a given mime-type. A double-tap on the file in the browser will start the application with the file.
         REQ.1.6.2.8	Hidden files	The system shall by default hide the system files (such as the soup database). The user shall have the ability to change that.
         REQ.1.6.2.9	Files annotations	The system shall allow the user to add annotations to a file, or to edit and delete them.
         REQ.1.6.2.10	Prefered folders	The system shall allow the user to keep a list of his/her favorites folders, and to select one of them for browsing.
         REQ.1.6.2.11	Last visited folder	The system shall allow the user to access a list of the last browsed folders, and to select one of them for browsing.
         REQ.1.6.2.11	Last used document	The system shall allow the user to access a list of the last used files, and to select one of them for manipulation.

      3. Calculator

         REQ.1.6.3.1	Calculator	The system shall provide the user a calculator, which can be used in the following modes: simple scientific
         REQ.1.6.3.2	Calculation bases	The system shall allow the user to chose the Numeric Base for calculation from the following bases: binary octal decimal hexadecimal The system shall allow the user to choose the Trigonometric Base for calculation from the following bases: degrees gradients radians
         REQ.1.6.3.3	Functions	In scientific mode, the system shall allow the user to select a function to be executed from a library of functions. The following libraries will be available: mathematic financial
         REQ.1.6.3.4	Programmable	In scientific mode, the system shall allow the user to add new functions (coded in Ruby) and to save them in a user library.
         REQ.1.6.3.5	Plotting	In scientific mode, the system shall allow the user to plot 2D data.
         REQ.1.6.3.6	Library plug-ins	The system shall allow the user to install and use third party libraries for the calculator.
         REQ.1.6.3.7	Convertor	The system shall provide the user a way of converting values from a unit to another unit. The user shall have the ability to enter new convertion formulas.
         REQ.1.6.3.8	Sharing functions	The system shall allow the user to send functions and libraries to another device (Ruby or plug-in).

      4. Universal IR remote control

         REQ.1.6.4.1	Remote control	The system shall provide the user the ability to use the device as a remote control for any appliance.
         REQ.1.6.4.2	IR signal recording	The system shall allow the user to record and store an IR signal from an existing device to be used later.
         REQ.1.6.4.3	Remote control designing	The system shall allow the user to create a virtual remote control and to add a labeled button link to a given recorded IR signal.

      5. Drawing tool

         REQ.1.6.5.1	Quality drawing	The system shall provide the user a tool for quality hand drawing.
         REQ.1.6.5.2	Drawing import/export	The system shall allow the user to import an image or export a drawing to and from any image format where a translator is available.
         REQ.1.6.5.3	Drawing goodies	The system shall provide the user all the following drawing tools: layers variable brush size color palettes image's area copy/cut/paste etc...
         REQ.1.6.5.4	Drawing size	The system shall provide the user the ability to draw on an image bigger than the screen resolution.

   7. User tailoring

      This section specifies all the user's options when configuring his/her device.

      1. User interface

         REQ.1.7.1.1	User handedness	The system shall allow the user to specify his/her handedness. Several adaptations shall be made according to the handedness: position of the vertical scrollbar
         REQ.1.7.1.2	Font selection	The system shall allow the user to change the font used on the GUI, as well as the default size of the characters.
         REQ.1.7.1.3	System sounds	The system shall allow the user to select the sounds to play when a system event occurs.
         REQ.1.7.1.4	Sound volume	The system shall allow the user to tune the volume of the sound ouput to the device.

      2. Personal information

         REQ.1.7.2.1	Persona information	The system shall allow the user to enter his/her information as a contact entry.
         REQ.1.7.2.2	Persona business card	The system shall allow the user to simply beam/fax/attach his business card from his/her contact entry.
         REQ.1.7.2.3	Multiple personae	The system shall support multiple users. The device should be allowed to be shared between several users.

      3. Time, date, localization

         REQ.1.7.3.1	Time and date	The system shall allow the user to set or change the date and time at any given moment. The time can be specified in 12 hours or 24 hours.
         REQ.1.7.3.2	System localization	The system shall allow the user to change the system language to any of the ones supported by the system.
         REQ.1.7.3.3	Application localization	The system shall allow every installed application to be aware of the current localization. It shall help localize the application.

      4. Modes

         REQ.1.7.4.1	Use modes	The system shall allow the user to group settings and applications launched under an unique name.
         REQ.1.7.4.2	Use mode selection	The system shall provide the user the possibility of selecting a mode of use for his/her device or of specifying when the mode shall be switched on.
         REQ.1.7.4.3	Default use mode	The first time the user uses the system, it shall create a default mode, called Normal, which will be used when no other mode is created.

      5. Basic applications

         REQ.1.7.5.1	Application settings	The system shall provide the user the ability to easily change or set the settings of any application installed on the device.

      6. Location

         REQ.1.7.6.1	Location data	The system shall allow the user to enter information on the location he/she is at. Information is entered as a Contact entry.
         REQ.1.7.6.2	Location selection	The system shall allow the user to create more than one location and to select his/her current location from this list.
         REQ.1.7.6.3	Location change	The system shall allow the user to specify settings to be changed according to his/her current location.

      7. Hardware related

         REQ.1.7.7.1	Auto-sleep delay	The system shall allow the user to specify the time after which a device that is no longer in use shall go into the sleep state.
         REQ.1.7.7.2	Backlight delay	The system shall allow the user to specify the time after which a device that is no longer in use shall turn its backlight off.

      8. Network

         REQ.1.7.8.1	Network settings	The system shall allow the user to select the network to use and to set the settings for it, according to his/her location.
         REQ.1.7.8.2	Protocol choice	The system shall allow the user to select the protocol to use from the following list: LAN ADSL PPP WIFI

   8. Privacy and recovery

      This section describes the requirements for data privacy and failure recovery

      1. Access protection

         REQ.1.8.1.1	PIN code activation	The system shall allow the user to set-up a PIN code and locking policy for the device.
         REQ.1.8.1.2	PIN lock	The system shall ask the user to enter their PIN code when the device has been locked by the user or when the device has gone into the sleep state.

      2. Safe

         REQ.1.8.2.1	Safe	The system shall provide a repository in which the user can store sensible documents. Access to this folder is restricted with a password.
         REQ.1.8.2.2	Safe encryption	The system shall encrypt the contents of the restricted repository whenever the user requests for it, or when the device goes into the sleep state.
         REQ.1.8.2.3	Safe opening	The system shall provide access to the contents of the restricted repository only when the user provides the correct password.

      3. Device wipe

         REQ.1.8.3.1	Wiping buttons sequence	The system shall allow the user to totally wipe out the contents of his/her device by pressing a certain combination of hardware buttons. No private data and no installed application shall remain after a wipe.
         REQ.1.8.3.1	Wiping protection	The system shall allow the user to enter a PIN code. The PIN code protects the device from a total data wipe by unauthorized users. This code shall be entered by the user when the wiping buttons sequence is pressed.

      4. Device recovery

         REQ.1.8.4.1	Data recovery	The system shall allow the user to recover data on the device from a host computer when the user cannot use the input hardware. This shall be activated by a specific hardware button sequence.

   9. External functions

      This section contains the specifications that can be satisfied by a relation host/device.

      1. Data synchronization

         REQ.1.9.1.1	Synchronization	The system shall allow the user to synchronize his/her device with a host computer. The synchronization shall be performed on the following data: contacts diary events notes settings users files and data installed applications
         REQ.1.9.1.2	Sync protocol	The system shall implement the SyncML protocol.
         REQ.1.9.1.3	Sync medium	The system shall allow the user to synchronize his/her device accross any communication medium known by the system.
         REQ.1.9.1.4	Sync between devices	The system shall allow the device to be synchronized with another device. In this case, the user shall have more control over what must be synchronized.

      2. Back-Up

         REQ.1.9.2.1	Device back-up	The system shall allow the user to perform a complete backup of the device onto a host computer or on a removable storage memory.

      3. Application installation

         REQ.1.9.3.1	Application installation	The system shall allow the user to install new applications distributed in a package file.
         REQ.1.9.3.2	Installation source	The system shall allow the installation of applications through any communication medium available. It shall also be possible for the user to install an application from a web browser or from any TCP/IP application, such as FTP.
         REQ.1.9.3.3	Application package	To distribute an application, the application author shall create a package file which is a zip file that contains the TGZ of the application/service/lib/data to install and an XML document created by the author of the package. This document shall provide information on the package for the pkg-installer, such as whether or not the package must be installed in the internal store. The information contained in the XML document are : author ID package ID parent package ID (if any) release date/version release flag (new,update,force update) package type (app,service,lib,data) package subtype (agent/server/low_level/lib/add-on/file/soup) package classification (game/tool...) contents description forced store location licence text to display other package required (installation failed if not present) compressed and flattened size compressed and flattened checksum mime-type of the files handled by the application memory/power consumption range (if known) when the application is IDLE when the application is WORKING
         REQ.1.9.3.4	Installed application	When an application is installed, it shall be in an application folder named as the application. It shall contain all the files needed by the application that are distributed with it.
         REQ.1.9.3.5	Installation target	The system shall allow the user to install an application in an internal or external storage.

   10. System functions

       This section describes the requirements not directly visible by the user.

       1. Data Storage

          REQ.1.10.1.1	Storage of data	The system shall provide an easy way to store and retrieve permanent data for any application running on the device.
          REQ.1.10.1.2	Data search	The system shall provide some criteria for which an application can seek permanent data.
          REQ.1.10.1.3	Storage availability	The system shall insure a high availability and performance level for the data stored.
          REQ.1.10.1.4	Storage security	The system shall insure that the data stored will always be retrievable and usable, and that an application can protect its data from un-authorized access.
          REQ.1.10.1.5	Data storage sharing	The system shall allow applications to share permanent data storage, unless otherwise specified.
          REQ.1.10.1.6	Storage location	The system shall allow the application to store its permanent data on the internal or external storage.
          REQ.1.10.1.7	Critical data	The system shall allow the application to define the importance of the data to be stored. Depending on the level of importance, the data may be directly stored on a storage device or will be queued for later storage.
          REQ.1.10.1.8	CF writing cycle	The system shall conserve the writing cycle when it is using a CF storage to increase its lifespan (typical writing cycle is C_FLASH_WRITING_MAX).
          REQ.1.10.1.9	Data preloading	The system shall allow an application to pre-load its data way before using it.

       2. File Annotation

          REQ.1.10.2.1	File annotation	The system shall allow the user to create/retrieve annotations on files and directories.
          REQ.1.10.2.2	Annotation definition	The system shall allow the user to define a file's annotation by a key, type and value. Annotations are stored and retrieved by using the key (which is always a string).
          REQ.1.10.2.3	System annotations	For every files, the system shall defines the following annotations: mime type preferred Application (if any) sharing rights CRC owner (system or user) date of last sync

       3. Monitoring

          REQ.1.10.3.1	Vital signs monitoring	The system shall monitor the following status of the device continuously: battery consumption battery level CPU activity memory consumption storage consumption touch-screen digitalizer activity
          REQ.1.10.3.2	Battery limit	The system shall warn the user when the level of the battery reaches C_WARNING_LEVEL_BATTERY and will go to sleep immediately when the level of the battery reaches C_MINIMUM_LEVEL_BATTERY.
          REQ.1.10.3.3	Battery conservation	When the user has not interacted with the device for more than C_MAXIMUM_USER_INACTIVITY, the system shall turn off the unecessary hardware features (given that no application is active) : screen backlight
          REQ.1.10.3.4	Device inactivity	The system shall go into the sleep state when there is no activity on the device (ie, no user input and low CPU load) for more than C_MAXIMUM_SYSTEM_INACTIVITY.
          REQ.1.10.3.5	Running applications	The system shall monitor the applications running at any given time. It shall provide this list on request.
          REQ.1.10.3.6	Applications statistics	The system shall maintain statistic information on the applications that are running or that have already ran. The statistics are the following: CPU usage memory usage battery consumption running time When an application is running, their statistics shall be available in real-time, otherwise an average,minimum and maximum value shall be kept.
          REQ.1.10.3.7	Application termination	The system shall terminate any application that uses too much resources. It will not be possible to launch another user selected application.
          REQ.1.10.3.8	System availability	The system shall monitor its components and be ready to restart failed ones.

       4. Embedded programming language

          REQ.1.10.4.1	Onboard programming	The system shall allow the user to write and execute scripted programs directly on the device.
          REQ.1.10.4.2	Onboard language	The system shall use Ruby as the embedded programming language.
          REQ.1.10.4.3	Ruby integration	The system shall fully integrate the Ruby programming language, allowing the user to program the following action: Output data (on screen, in a note, in a file) create simple application create simple GUI create or use Note, Contact or Diary event use the storage system access to the communication medium
          REQ.1.10.4.4	Ruby debuging	The system shall allow the user to debug, trace, and perform step-by-step execution of his/her program.
          REQ.1.10.4.5	Ruby extension	The system shall allow any application to be able to integrate Ruby code, modifiable by the user, in order to extend or customize itself. It shall be possible to set a Ruby function as callback for a GUI event.
          REQ.1.10.4.6	Ruby storage	The system shall allow an application to store ruby code in: the storage system a file annotation a text file

       5. Datatype Translation

          REQ.1.10.5.1	Datatype translator	The system shall provides a data translator that handle the translation of a certain type of data, into another type of data.
          REQ.1.10.5.2	Translator add-on	The system shall support add-ons added to a translator that augment the number of datatypes supported. An add-on must contain the following information: a name (e.g : JPG translator) a mime-type (e.g : image/jpeg) a file extension (e.g : jpg)
          REQ.1.10.5.3	Included translators	The system shall provide to the user the following translators: image translators sound translators
          REQ.1.10.5.4	Translator availability	The system shall allow any application to use the installed translators.
          REQ.1.10.5.5	Translator list	The system shall allow the user to list the installed translators and add-ons.

       6. Device's Fleet

          REQ.1.10.6.1	Fleet membership	The system shall allow a device to be part of a device fleet within the same organization.
          REQ.1.10.6.2	Fleet administrator	The system shall grant access of the device to the administrator of the fleet. According to organization policies, the admin shall have the following rights: set-up the system for a given user (lock or restrict access to the settings) disable the possibility to create new personae forbid the installation of new software by the user (or restrict it by categories) restrict access to certain applications according to the time manage the contents of the device perform remote maintenance and troubleshooting
          REQ.1.10.6.3	Fleet synchronization	The system shall allow the device to be synchronized with the fleet database. This synchronization shall also take into account the application that should be installed or updated.
          REQ.1.10.6.4	Fleet monitoring	The system shall allow the fleet administrator to receive the status of the devices in real-time, when connected to the organization network. The status report shall contain the following informations: presence on the network (since ...) last sync statistics (battery,RAM,CPU,storage)
          REQ.1.10.6.5	Fleet's device back-up	The system shall allow the fleet administrator to perform a complete backup of the system. It shall also simplify the cloning of a device from a backup or from an existing device.

       7. Low level

          REQ.1.10.7.1	Device reboot	The system shall provide the user with the option to reboot the device without using any hardware button sequences.
          REQ.1.10.7.2	Device power-off	The system shall put the device in the Sleep state when the user presses the hardware power-off button. The system shall also provide a way to power-off the device without using the hardware button.
          REQ.1.10.7.3	Device power-on	The system shall put the device in the Operational state when the user presses the hardware power-on button. The system shall also provide a way to power-on the device without using the hardware button such as by a registered time event.

   11. Interaction with the user

       This section contains the overall requirements allocated to the user interface.

       1. Graphical interface

          REQ.1.11.1.1	UI consistency	The system shall provide the user with a GUI that shall be consistent with the other tools used by the user.
          REQ.1.11.1.2	UI compatibility	The system shall provide the user with a GUI compatible with the user's intended use and tasks.
          REQ.1.11.1.3	UI incitement	The system shall insure that at any moment, the user will only have access to the available commands. The list of expected values are proposed and the entry fields display the expected format of the input.
          REQ.1.11.1.4	UI grouping and distinction	The system shall group information of same type, either by format or by position. It shall also use a different presentation for distinct information.
          REQ.1.11.1.5	UI feedback	The system shall give feedback for every action performed by the user. It shall also indicate the current states or modes, informs the user when there is long processing, display the processing currently done by the system, and always show the user's input.
          REQ.1.11.1.6	UI legibility	The system shall insure that the GUI can be read easily at all times.
          REQ.1.11.1.7	UI homogeneity	The system shall provide to the user with an homogenous GUI: applications and slips must follow the same content organization the same vocabulary must be used for all system commands command's syntax must be consistent throughout the system
          REQ.1.11.1.8	UI adaptability	The system shall allow the user of the GUI to easily adapt it to his/her needs or requirements.
          REQ.1.11.1.9	UI safety	The system shall ask the user to validate commands that are critical or that can't be interrupted. It shall also allow the user to interrupt long processing and support traceback.
          REQ.1.11.1.10	UI errors processing	The system shall offer protection against error to a certain extent: non usable commands shall not be accessible use list of possible values as often as possible detect errors as soon as possible minimize user input warn the user when there is a risk of data lost It shall also allow the correction of errors: display comprehensible error messages at the appropriate times highlight erroneous fields or widgets allow the error to be easily corrected allow the user to explore and learn the system
          REQ.1.11.1.11	UI concision	The system shall display only relevant information and reduce the number of actions needed to perform a task: minimize the user's required input minimize the amount of material the user needs to read do not request input from the user that could be inferred by the system avoid having the user recall too much information from previous displays do not request the user to do a calculation that could be done automatically
          REQ.1.11.1.12	UI abilities	The system shall provide the user with the following abilities: copy/paste of data across applications

       2. Input interface

          REQ.1.11.2.1	Pen based interaction	The system shall allow the user to use a pen or any pen-like device to interact with.
          REQ.1.11.2.2	Hardware buttons interaction	The system shall allow the user to use the hardware button of the device for interaction.
          REQ.1.11.2.3	Pen input pad	The system shall provide the user with the use of a special slip to perform pen stroke input in a designated area.
          REQ.1.11.2.4	Pen input fullscreen	The system shall provide the user with the use of the whole screen as a designated area for pen stroke inputs.
          REQ.1.11.2.5	Recognition engines	The system shall allow the user to install any third-party pen stroke engines.
          REQ.1.11.2.6	Keyboard input	The system shall provide the user with an onscreen keyboard when ever he/she requests for it.
          REQ.1.11.2.7	Data-field awareness	The system shall provide the user with the input mode that matches the type of the field the user enters data with.
          REQ.1.11.2.8	Input add-on	The system shall be extendable by the addition of plug-ins, which adds new inputs mediums.

       3. Voice/Speech Interaction

          REQ.1.11.3.1	Voice commands	The system shall provide the user with the ability to give commands to the device by speaking keywords.
          REQ.1.11.3.2	Voice input	The system shall allow the user to enter data by speaking, when s(he) is in the input mode.
          REQ.1.11.3.3	Speech output	The system shall be able to output data by generating speech. This ability shall be given to any application that requires it.

       4. Sounds Interface

          REQ.1.11.4.1	Operation sounds	The system shall use sounds during its operations in a non-intrusive way.
          REQ.1.11.4.2	Sound events	The system shall play sounds in the following events: pen tap slip opening system alert low battery application crash
          REQ.1.11.4.3	Sound volume	The system shall respect the current audio volume (set by the user) and shall not play when the audio output is mute.
          REQ.1.11.4.4	Sound change	The system shall allow the user to change the sounds.

   12. Performances and Limitations

       This section specifies the system functions and requirements performances and limitations.

       1. General

          REQ.1.12.1.1	RAM saving	The system functions shall have for priority to conserve RAM as much as possible.
          REQ.1.12.1.2	Storage saving	The system functions shall have for priority to conserve storage space as much as possible.
          REQ.1.12.1.3	Power saving	The system functions shall use battery in a conservative manner.
          REQ.1.12.1.4	Processing saving	The system functions shall use the CPU without wasting cycles, thus conserving battery.
          REQ.1.12.1.5	Reaching the limits	The system shall try to avoid reaching the limits of its power, CPU, RAM or storage. When necessary the system shall inform the user of the problem and help him/her resolve it.
          REQ.1.12.1.6	User interaction under load	The system functions shall be able to accept and give feedback to an user command, even if the system is busy. The user shall not have to wait for the system to be available more than C_MAXIMUM_AVAILABILITY_DELAY.
          REQ.1.12.1.7	Starting time	The system shall be able to start a function in less than C_MAXIMUM_STARTING_TIME.

       2. User Training

          N/A.

       3. Personal Information Manager

          REQ.1.12.3.1	Diary show	The system shall make the display of the diary's event visible as much as possible, despite the event's display style.
          REQ.1.12.3.2	Event categories	The system shall allow the user to create as many event categories as possible unless there is storage space constraint
          REQ.1.12.3.3	Link list	The system shall allow the user to enter as many links as (s)he needs. However, the user needs to take into account the storage space available.
          REQ.1.12.3.4	String length	The system shall not limit the size of any string in any Diary event, contact entry or notepad note.
          REQ.1.12.3.5	User's fields	The system shall not restrict the number of fields the user can add to an event or to a contact (unless there is storage space constraint).
          REQ.1.12.3.6	Event capacity	The system shall not limit the number of event a user can create (unless there is storage space constraint).
          REQ.1.12.3.7	Notification snooze	The system shall allow the user to snooze the notification of an event as many times as (s)he wishes.
          REQ.1.12.3.8	View profiles	The system shall allow the user to create as many contact viewing profiles as (s)he need (unless there is storage space constraint).
          REQ.1.12.3.9	Contacts limit	The system shall allow the user to create as many contact entries as (s)he needs (unless there is storage space constraint).
          REQ.1.12.3.10	Contact photo	The system shall not limit the size or the number of photo the user can attach to a contact entry (unless there is storage space constraint).
          REQ.1.12.3.11	Notes limit	The system shall allow the user to create as many notes as (s)he need (unless there is storage space constraint).
          REQ.1.12.3.12	Paperroll type	The system shall not limit the number of paperroll types that can be installed and used by the user.
          REQ.1.12.3.13	Filling folder	The system shall allow the user to create as many filling folders as (s)he needs (unless there is storage space constraint).
          REQ.1.12.3.14	Contact display	The system shall be able to display a contact in any display profile in less than C_MAXIMUM_DELAY_CONTACT_DISPLAY.
          REQ.1.12.3.15	Note display	The system shall be able to display a note in less than C_MAXIMUM_DELAY_NOTE_DISPLAY.
          REQ.1.12.3.16	Diary display	The system shall be able to display a daily planning in less than C_MAXIMUM_DELAY_DIARY_DISPLAY.
          REQ.1.12.3.17	Contact search	The system shall be able to find a contact in less than C_MAXIMUM_DELAY_CONTACT_SEARCH, for 1000 contact entries.

       4. World Connected

          REQ.1.12.4.1	Communication medium limitation	The system shall take into account the limitations of the communication medium available on the device.
          REQ.1.12.4.2	TCP/IP	The system shall use the TCP/IP protocol whenever possible, for all the available communication medium.
          REQ.1.12.4.3	Host computer	The system shall allow a host computer to be the master of several slave devices at any one time. It shall not allow a host computer in "slave mode" to be shared among several master devices.
          REQ.1.12.4.4	On-the-fly network	The system shall not restrict the number of devices which can join a On-the-fly network.
          REQ.1.12.4.5	HTML cache size	The system shall limit the size of the HTML cache according to the user's setting, and with respect to the capacity of the device.
          REQ.1.12.4.6	Emails storage	The system shall not limit the number of email a user can store on his/her device (unless there is storage space constraint).
          REQ.1.12.4.7	Mail accounts	The system shall not limit the number of email account a user can mark for emails retrieval. (with respect to the storage capacity)
          REQ.1.12.4.8	Services limit	The system shall limit the number of simultaneous network services accessed, to the value set by the user.
          REQ.1.12.4.9	Services performance	The system shall limit the processing power used by network services, and give priority to the local processing needs.
          REQ.1.12.4.10	Stream repository	The system shall not limit the number of data stream stored in the repository (unless there is storage space constraint).

       5. Pocket Entertainment

          REQ.1.12.5.1	MP3 playlists	The system shall allow the user to have as many playlists as (s)he wishes (unless there is storage space constraint).
          REQ.1.12.5.2	MP3 playlist contents	The system shall not limit the number of entries a user can place in a playlist (unless there is storage space constraint).
          REQ.1.12.5.3	MP3 play start	The system shall be able to start playing a MP3 file in less than C_MAXIMUM_DELAY_MP3_PLAY after the user selected a file with an average size close to C_AVERAGE_MP3_SIZE.
          REQ.1.12.5.4	Movie play start	The system shall be able to start playing a movie file in less than C_MAXIMUM_DELAY_MOVIE_PLAY after the user selected a file with an average size close to C_AVERAGE_MOVIE_SIZE.

       6. Operating Environment

          REQ.1.12.6.1	Application title length	The system shall truncate the application titles that are too long to be displayed in the Top bar.
          REQ.1.12.6.2	Bottom bar plugins	The system shall not restrict the number of available plug-ins for the Bottom bar. It shall only restrict the number of plug-ins used according to the space available on the bottom bar.
          REQ.1.12.6.3	Installed applications	The system shall allow the user to install as many applications that (s)he wishs (unless there is storage space constraint).
          REQ.1.12.6.4	Application folder	The system shall allow the user to create as many folders as needed, and to cross-fill it with as many applications as (s)he wishes. However, the user must not exceed the storage capacity.
          REQ.1.12.6.5	Recently used list	The system shall allow the user to specify how many elements can be left in the list of the most recently used application.
          REQ.1.12.6.6	More used list	The system shall allow the user to specify how many elements can be left in the list of the most used application.
          REQ.1.12.6.7	Favorites list	The system shall allow the user to specify how many elements can be left in the list of the favorites application.

       7. Pocket computing

          REQ.1.12.7.1	Find performances	The system shall be able to find a document in less than C_MAXIMUM_DELAY_FIND.
          REQ.1.12.7.2	File browser listing	The system shall not restrict the number of files that can be displayed in a listing. However, the user must not exceed the storage capacity.
          REQ.1.12.7.3	Mime-type	The system shall not allow the user to set more than one mime-type for a given file.
          REQ.1.12.7.4	Programmable calculator	The system shall not restrict the amount of functions a user can add to the calculator. However, the user must not exceed the storage capacity.
          REQ.1.12.7.5	Calculator's plug-ins	The system shall not restrict the number of third party plug-ins the user installs on his/her device. However, the user must not exceed the storage capacity.
          REQ.1.12.7.6	Remote controls	The system shall allow the user to create and store as many virtual remote controls as necessary. However, the user must not exceed the storage capacity.
          REQ.1.12.7.7	Painting	The system shall allow the user to create and store as many paintings as (s)he wishes. However, the user must not exceed the storage capacity.

       8. User tailoring

          REQ.1.12.8.1	Personae	The system shall be able to store as many personae as needed. However, the user must not exceed the storage capacity.
          REQ.1.12.8.2	Localization	The system shall restrict the number of localizations possible to only one per personae.
          REQ.1.12.8.3	Use modes	The system shall not restrict the number of Use modes the user can create and operate. However, the user must not exceed the storage capacity.
          REQ.1.12.8.4	Locations	The system shall allow the user to create as many locations as needed. However, the user must not exceed the storage capacity.

       9. Privacy and recovery

          N/A.

       10. External functions

           N/A.

       11. System functions

           REQ.1.12.11.1	Data storage limit	The system shall allow the user to store as much data as possible, as long as the storage capacity at the location is not used up.
           REQ.1.12.11.2	Writing data	The system shall take less than C_MAXIMUM_DATA_STORING_DELAY to permanently store a given data.
           REQ.1.12.11.3	Reading data	The system shall take less than C_MAXIMUM_DATA_RETREIVING_DELAY to retreive a given data.
           REQ.1.12.11.4	Finding data	The system shall take less than C_MAXIMUM_DATA_FINDING_DELAY seconds to locate a given data.
           REQ.1.12.11.5	Annotation limit	The system shall allow the user to create as many annotations on a file as needed. However, the user must not exceed the storage capacity.
           REQ.1.12.11.6	Vital signs	The system shall probe the vital signs every C_DEVICE_BEAT.
           REQ.1.12.11.7	Onboard programming	The system shall allow the user to create as many Ruby scripts as needed. However, the user must not occupy more than the storage area.
           REQ.1.12.11.8	Translators	The system shall allow the user to install as many translator plug-ins as needed. However, the user must not occupy more than the storage area.
           REQ.1.12.11.9	Powering off	The system shall be powered-off by the user in less than C_MAXIMUM_POWEROFF_DELAY.
           REQ.1.12.11.10	Powering on	The system shall be powered-on by the user in less than C_MAXIMUM_POWERON_DELAY.

       12. Interactions with the user

           REQ.1.12.12.1	User pen input	The system shall be able to recognize an user's pen input gesture and be able to demonstrate it in the input field in less than C_MAXIMUM_GESTURE_RECO_DELAY.
           REQ.1.12.12.2	Input add-ons	The system shall allow the user to install as many input add-ons as needed. However, the user must not exceed the storage capacity.
           REQ.1.12.12.3	Reco engines	The system shall allow the user to install as many recognition engines as needed. However, the user must not exceed the storage capacity.

   13. Links between system functions and states

       This section uses tables to summarize the relation between the system's performance characteristics states. For each requirement, the table indicates which state the requirement applies to.

       The table is in Chapter 7.

   14. External interface requirements

       This section describes the requirements for interfacing this system with other systems.

       1. Interface to a host computer

          The purpose of this interface is to synchronize the device or to run the device into the master/slave/relay modes with a host computer. The interface is described in the corresponding ICD.

       2. Interface to the fleet

          The purpose of this interface is to integrate the device in a group of devices owned by the same entity. The interface is described in the corresponding ICD.

       3. Interface to the on-the-fly network

          The purpose of this interface is to allow several devices connected by communication mediums to share data and applications. The interface is described in the corresponding ICD.

       4. Interface to another device

          The purpose of this interface is to allow the synchronization of two devices. The interface is described in the corresponding ICD.

       5. Interfaces to an utilitary device

          The purpose of these interfaces is to allow a device and an utilitary device, such as a printer, to communicate. The interfaces are described in the corresponding ICDs.

   15. Physical requirements

       This section describes the requirements concerning the physical characteristics that a device shall have in order to be compatible with the system.

       1. Mobility

          REQ.1.15.1.1	Device size	The device shall be small enough to fit in the user's: hand pocket bag depending on the needs of the user.
          REQ.1.15.1.2	Device power	The device shall have an autonomous power source that is rechargeable by the user to any desired level.

       2. User interaction

          REQ.1.15.2.1	Device's output	The device shall have a display large enough to satisfy the end user's needs.
          REQ.1.15.2.2	Display orientation	The device's display shall support both portrait and landscape data displays.
          REQ.1.15.2.3	Display readability	The device's display shall be read easily by the end user.
          REQ.1.15.2.4	User's input	The device shall provide the user a way to enter data with: a pen an external or internal hardware keyboard connected to the device
          REQ.1.15.2.5	Device audio output	The device shall support audio output at a satisfactory level for the end user.

       3. Communication

          REQ.1.15.3.1	Serial connection	The device shall integrate a serial connector.

       4. Software needs

          REQ.1.15.4.1	CPU Power	The device shall contain a CPU matching the needs of the end user. For the system to work satisfactory, it shall be of C_MINIMUM_CPU_SPEED.
          REQ.1.15.4.2	RAM required	The device shall contain at least C_MINIMUM_NEEDED_RAM of Random Access Memory.
          REQ.1.15.4.3	Storage required	The device shall have at least C_MINIMUM_NEEDED_MEMORY megabytes of storage.

       5. Operating system

          REQ.1.15.5.1	QNX support	The device hardware shall be supported by the QNX OS.

   16. System quality factor
       1. Reliability

          The system shall be capable of accomplishing a required function under specified conditions and for a requested period.

          REQ.1.16.1.1	MTBF	The system shall provide the user a reliable device which will have a "Mean Time Before Failure" of C_SYSTEM_MTBF days.
          REQ.1.16.1.2	Stored data	The system shall not lose stored data when conditions of valid termination are not met.
          REQ.1.16.1.3	Behaviors	The system shall offer the user constant behavior at all times and under all situations.

       2. Maintainability

          In any given condition, the system shall be maintained or restored, within a given time interval, to a state in which it can accomplish the required function.

          REQ.1.16.2.1	Maintenance	The system shall minimized the time the device needs to spend in maintenance.
          REQ.1.16.2.2	Failure recovery	The system shall be able to recover from a critical failure in C_MAXIMUM_RECOVERY_DELAY.
          REQ.1.16.2.3	Resaturation	The system shall allow the user to restore it after a serious hardware failure in less than C_MAXIMUM_RESTORE_DELAY.

       3. Availability

          The system shall be in a state to accomplish a required function, at any time, for any duration, and in any situation. This is assuming that there is a sufficient supply of outside resources.

          REQ.1.16.3.1	Availability	The system shall be available for user interaction under any condition with less than C_MAXIMUM_DELAY_UNAVAILABILITY.

       4. Integrity

          The system shall be protected against deteriorations or access by unauthorized users.

          REQ.1.16.4.1	Application installation	The system shall insure that the installation by a third party application (via package) cannot compromise the integrity of the system.
          REQ.1.16.4.2	Application deletion	The system shall insure that the deletion by a third party application (via package) cannot compromise the integrity of the system.
          REQ.1.16.4.3	Failures	The system shall maintain the integrity of the system when failures occurs.

       5. Efficency

          The system shall confine in those resources strictly necessary for the accomplishment of a function to the user.

          REQ.1.16.5.1	Processing power allocation	The system shall give the preference for CPU, RAM, and memory resources to the application used at a given moment.
          REQ.1.16.5.2	Power level	The system shall adapt the processing power allocated for the application to the current battery level in order to conserve energy.

   17. Flexibility and expandability

       This section specifies the fields in which consider the possibility of the system's modification and expansion. It specifies the particular components of the system which must be able to withstand expansion without bringing the design into question.

       1. Software plug-ins

          REQ.1.17.1.1	System plug-ins	The system shall support the addition of plug-ins for any of its components, and it shall make use of them as much as possible.
          REQ.1.17.1.2	Plug-in unavailability	The system shall support the fact that a required plug-in could be unavailable or missing without leading to a fatal error.
          REQ.1.17.1.3	Plug-in list	The system shall allow the user to list all the plug-ins installed for a given component of the system.
          REQ.1.17.1.4	Plug-in protocol	The protocol used by the system plug-in must be well known and documented with care.

       2. Hardware expansion

          REQ.1.17.2.1	Memory change	The system shall maintain a high quality level of services for the user if the memory on the device is lowered. It shall make full use of a memory expansion.
          REQ.1.17.2.2	Storage change	The system shall maintain a high quality level of services for the user if the storage on the device is lowered. It shall make full use of a storage expansion.
          REQ.1.17.2.3	New expansion hardware	The system shall be able to withstand the addition of hardware designed to enhance the functionalities of the device. A simple driver or plug-in shall allow the user to use this new hardware.
          REQ.1.17.2.4	Expansion hardware removal	The system shall be able to withstand the removal of hardware designed to enhance the functionalities of the device.

   18. Portability

       The section specifies the portability requirements that are applicable to the system. Portability refers to the ability to easily transfer material to another hardware/software environment.

       1. To another software environment

          N/A.

       2. To another hardware environment

          REQ.1.18.2.1	Hardware dependency	The system shall not depend on the device's hardware. It shall rely on the OS to handle the hardware.
          REQ.1.18.2.2	Hardware drivers	The OS shall include all the drivers needed to control and command the hardware of the device.

2. Design and Production

   This section is used to define the general rules by applying a standard recognized by future users. This standard governs the choices the designer has to define and specify the design and production. These rules must not compromise the technical performance requirements.

   1. Design process

      N/A.

   2. Ergonomics

      N/A.

3. Documentation

   This section specifies the general documentation requirements regarded as essential for the implementation, use and maintenance of the system.

   1. Pre-development

      REQ.3.1.1	System design	The design of the system shall be documented in a design document, to be reviewed by peers.
      REQ.3.1.2	Project planning	The planning of the project shall be documented in a specific document, to be reviewed by peers.
      REQ.3.1.3	Interfaces	Each interface of the system shall be documented in a separate document, to be reviewed by peers.

   2. Development

      REQ.3.2.1	Software specifications	A document shall list the requirements allocated to every software component of the system. These documents shall be reviewed by peers and are available before the start of any development.
      REQ.3.2.2	Software design	Design of each software component shall be documented in a separate document, to be reviewed by peers.
      REQ.3.2.3	Software files	A document included with any software component shall be drafted. It shall contain every relevant information related to the software.

   3. Maintenance

      REQ.3.3.1	Software evolution	Every software evolution after its initial release shall be documented in the software documents.

   4. User support

      REQ.3.4.1	User guide	A user guide shall be drafted and completed at the time of delivery of the final product. It shall explain in an user-friendly way to the user how to make the best of his eQip system.
      REQ.3.4.2	Application developer guide	A developer guide shall be drafted and completed as soon as the major features of the system are available on a prototype. It shall explain everything a developer needs to know to create an application for the eQip system.
      REQ.3.4.3	GUI guideline	A document shall describe and debate over the way in which a Graphical User Interface shall be designed on the eQip system.
      REQ.3.4.4	Maintenance guide	A document shall describe how to maintain the eQip system once the final product has been released.

4. Priority

   If necessary, this section specifies the order of priority between conflicting requirements, otherwise it is not applicable.

   • REQ.1.10.1.3 shall have priority over REQ.1.10.1.8
   • REQ.1.10.1.4 shall have priority over REQ.1.10.1.8
   • REQ.1.12.1.2 shall have priority over REQ.1.12.1.1
   • REQ.1.12.1.4 shall have priority over REQ.1.12.1.2
   • REQ.1.12.1.4 shall have priority over REQ.1.12.1.1