System/Segment Specifications
of the eQip project

Version 0.9 (07/15/02)

Jean-Louis Villecroze eQip Development Team
Abstract


This document, drafted by the eQip project team contains all the requirements that the project needs to satisfy.


Contents


1. Field of Application

  1. Identification

    This specification defines the requirements concerning functional and technical characteristics, the design and production constraints, and the quality insurance of the eQip system.

  2. General information concerning the system

    The software architecture constituing the system, is to be used for a Personal Digital Assistant handheld computer and for Information Appliances.

  3. General information concerning the document

    The purpose of this document is to specify the requirements for the system characteristics and to define the planned methods for verifying them. All constraints relating to the use of the system which could influence its design and production process are also specified here.



2. Referenced Documents

  1. Specification

    N/A.

  2. Standards

    N/A.

  3. Other publications

    LabelTitleVersion
    [PROPOSAL]eQip Project Proposal0.32



3. System Requirements

  1. Definition

    The purpose of this section is to provide information concerning the composition of the system, its tasks and uses, and its operating states. This information does not represent requirements , but instead is presented to justify and help the reader understand the rest of this chapter.

    1. Overall description

      The system will be used mainly in a device carried by an individual in their pocket or bag. The device will be a mobile computer with limited resources (storage,RAM,battery). It will support pen inputs and voice commands from the user. The system will also be used embedded in an appliance or in a vehicle.

    2. Tasks and uses

      From a user's point of view, the system running on a device shall be able the fullfill the following tasks:

      • tasks related to that of a PIM (Personal Information Manager) and Note organizer
      • ability to connect to a local network and/or to Internet
      • can be used as a pocket entertainment system (games,movie,music)
      • can be used as a tool for every-day life
      • ability to run third-party softwares
      • ability to access to external hardware

    3. Target user

      An individual who needs a smart and powerful device present with them at all times and in all places.

    4. States

      During it's exploitation, the system can be in any of the following states :

      • Synchronizing (S)

        The system is synchronizing its data with an external host computer.

      • Tyding (T)

        The system is performing tasks critical to the maintenance of it's operational state.

      • Operational (O)

        The system is ready for user interaction, or is performing user commands.

      • Asleep (A)

        The system is conserving its battery life by waiting for a user action, or a programmed event to enter in the Operational or Tyding states.

      • Communicating (C)

        The system is using a communication medium.

      • Mute (M)

        The system cannot to use any communication medium or may not be permitted to do so.

  • Characteristiques

    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 :

        2. touch-screen calibration
        3. owner information
        4. date, time and location

        5. 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.

        6. 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 :

        6. large application icon and name
        7. small application icon and name
        8. 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 ...)


        9. 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.

        10. 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.

        11. 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.