Software Requirements Specification Multi-touch …cs.joensuu.fi/~akheikki/RE/Project 2 - Multi-Touch Newspaper SRS.pdf · Software Requirements Specification for Multi-touch Newspaper

Copyright © 2002 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this document.

Software Requirements Specification

for

Multi-touch Newspaper

Version 1.0 approved

Prepared by Aki Heikkinen and Pankaj Jaiswal

Joensuu University

16.12.2009

Software Requirements Specification for Multi-touch Newspaper Page ii

Table of Contents 1. Introduction ........................................................................................................................... 1

1.1 Purpose ......................................................................................................................... 1 1.2 Document Conventions ................................................................................................. 1

1.2.1 Requirement priorization ........................................................................................... 1 1.3 Intended Audience and Reading Suggestions .............................................................. 2 1.4 Project Scope ................................................................................................................ 2 1.5 References .................................................................................................................... 2

2. Overall Description ............................................................................................................... 2 2.1 Product Perspective ...................................................................................................... 2 2.2 Product Features ........................................................................................................... 3 2.3 User Classes and Characteristics ................................................................................. 4

2.3.1 Administration-user characteristics ........................................................................... 4 2.3.2 Supportive-user characteristics ................................................................................. 5 2.3.3 End-user characteristics ............................................................................................ 5

2.4 Operating Environment ................................................................................................. 6 2.4.1 Care-house characteristics ........................................................................................ 6

2.5 Design and Implementation Constraints ....................................................................... 7 2.6 User Documentation ...................................................................................................... 7 2.7 Assumptions and Dependencies ................................................................................... 8

3. System Features ................................................................................................................... 8 3.1 Traditional Newspaper Usage Paradigma ..................................................................... 8 3.2 News and Multimedia .................................................................................................... 9 3.3 User Modes ................................................................................................................. 11 3.4 Administration-user mode (AMOD) ............................................................................. 11 3.5 Supportive-user (SMOD) ............................................................................................. 12 3.6 End-user Mode (UMOD) ............................................................................................. 13

4. External Interface Requirements ....................................................................................... 14 4.1 User Interfaces ............................................................................................................ 14 4.2 Hardware Interfaces .................................................................................................... 14 4.3 Software Interfaces ..................................................................................................... 15 4.4 Communications Interfaces ......................................................................................... 16

5. Other Nonfunctional Requirements .................................................................................. 17 5.1 Performance Requirements ........................................................................................ 17 5.2 Safety Requirements ................................................................................................... 17 5.3 Security Requirements ................................................................................................ 17 5.4 Software Quality Attributes .......................................................................................... 17

6. Other Requirements ............................................................................................................ 19 Use Case: 100-01 – Login and end-user profiles ................................................................ 19 Use Case: 200-01 – Request news from provider .............................................................. 21

7. Contribution For The Project ............................................................................................. 24

Software Requirements Specification for Multi-touch Newspaper Page iii

Revision History Name Date Reason For Changes Version

Initial version 5.12.2009 Writing intoduction 0.1 Workversion 11.12.2009 Adding initial document’s content to this

document and revising material 0.5

Detailed version 13.12.2009 Adding Visio-document and test-cases 0.9 Final version 16.12.2009 Finishing the project 1.0

Software Requirements Specification for Multi-touch Newspaper Page 1

1. Introduction

1.1 Purpose

The purpose of this specification document is to analyze possibilities and challenges regarding multi-touch technologies which could be used to produce traditional-like newspaper application for senior-class users. This specification document defines the users, their environment and produce list of possible requirements and features that can be applied to produce traditional-newspaper alike applications for specific group of end-users.

1.2 Document Conventions

In this section contains the most important document conventions. Abbrevations used in this document can be found from section appendix A: Glossary. Bold-style highlighting is used in the text when important concept is mentioned first time.

1.2.1 Requirement priorization

Each requirement in section 3 has priorization number from 1-5 (dispayed as P5, P4, P3, P2 or P1), in which the number 5 is the most important feature and number 1 is the least important feature. Guidline to use the priorization is following:

• Each feature priorized with number 5 shall be implemented to the system before any other feature.

• Features priorized with number 4 are subfeatures of the features with priorization of 5. These features shall be implemented to the system after all higher priorization features are implemented. However, in some cases when given subfeature is considered to be essential for the given parent feature, this subfeature can be implemented right after the parent feature is implemented.

• Each feature priorized with number 3 would be beneficial to implement to the sytem. These features are implemented only when all higher level of priorized features are implemented.

• Features priorized with number 2 are subfeatures of the features with priorization of 3. These features shall be implemented to the system after all higher priorization features are implemented. However, in some cases when given subfeature is considered to be essential for the given parent feature, this subfeature can be implemented right after the parent feature is implemented.

• Each feature priorized with number 1 are optimational features and should be implemented

to the system only after all the other higher priorization features are implemented.


1.3 Intended Audience and Reading Suggestions

This specification document is for developers who tend to produce multi-touch interface for representing traditional newspaper application. Project engineers can use this document for clarifying case-specific requirements for similar projects.

1.4 Project Scope

The scope of the project is to produce requirements and features that deals with new multi-touch technology associated with user-group of senior-class citizens. This document can be used as a base for defining case-specific requirement specifications regarding multi-touch interface newspaper applications. Requirements and features listed in this specification document are not meant to be final, instead they are meant to be guidelines for incomming projects regarding the subject.

1.5 References

This requirements specification document template bases on Karl E. Wieger’s copyrighted but freely shared SRS template (http://www.processimpact.com/process_assets/srs_template.doc). Permissions for this copyrighted SRS template includes using, modifying, and distributing. There are several other documents associated with this one. Use case document can be found from Appendix B: Use Case Models and the Vision document can be found from Appendix C: Vision Document. Test Cases for the system can be found from Appendix D: Test Cases. Other references used in this document include following web-references: http://www.billbuxton.com/multitouchOverview.html, http://en.wikipedia.org/wiki/Multi-touch, http://www.touchusability.com/multitouch/

2. Overall Description

2.1 Product Perspective

Multi-touch technology dates back to 1982, when Nimish Mehta at the University of Toronto developed the first finger pressure multi-touch display. Various companies expanded upon these inventions in the beginning of the twenty-first century. Mainstream exposure to multi-touch technology occurred in the year 2007, when Apple unveiled the iPhone and Microsoft debuted surface computing. The iPhone in particular has spawned a wave of interest in multi-touch computing, since it permits greatly increased user interaction on a small scale. This Is a extension of certain existing system .so the concept of multi touch has been used to develop this newspaper application. http://www.billbuxton.com/multitouchOverview.html


Figure 1. Produce perspective

2.2 Product Features

The product has some functionality or features that are listed as below. 1) it allows users to have multi touch with gestures 2) It allows user to have the color effect. 3) It allow user to have font effect. 4) It allow user to make the account and have the profile saved on it. 5) The MTA is also designed to cover adjusting options to address situations for impaired senses. 6) This kind of system is also design for user having lack of locomotors for example the people in the wheel chair. 7)This system make easy for those user who cannot remember means that difficult in memorizing and recalling so this issue can be addressed by implementing finger-print reading which will handle the whole login procedure. 8) It can have backup for the user data and database. 9) The system has option for using wireless earphones to prevent disturbing other users. 10) It is designed in such a way that it won’t take too much space and can be installed in any place 11) If MTA has an error that it can’t recover from by itself, such as the lack of internet connection than it will notify any current user and give contact information from where technical help can be achieved. 12) It is applied to all the mode of users.

APPLICATION

INPUT FROM MULTI-TOUCH SCREEN

TOUCHLIB

MULTI TOUCH EVENT

GESTURE EVENT


13) It has whole display controlling areas in both lower corners of the display. 14) It can have timing control with good accuracy to present the data. It can display the data as well as download within the given time. 15) The system have built-in multimedia player that can play following multimedia: video, sound

and picture files .The system built-in multimedia player shall be able to play following video file

formats: mp4, avi and swf.

16) It has facility to expand the data and make focus or highlight on the data the user is interested

in.

17) The system displays the data that it has downloaded to local hard-drive.

18) The system shall be passive.

19) The system shall use only up to 800GB for persisted news and multimedia and if more than it removes the news and multimedia from the hard drive

2.3 User Classes and Characteristics

The main end-users of MTA will be senior-class citizens of age at least 60 and who live in care-houses. They are presumed to have no experience with computers or involved technologies at all but they are assumed to know what is the real-world newspaper and how it can be used. In addition to main end-users there are two additional user types for the system: Administrative- and supportive-user. Below is presented major characteristics regarding the all user types.

2.3.1 Administration-user characteristics

Administration-user is a user who has the acceess to all system configuration options. These users are usually technical contact persons from company from which the MTA was purchased from. Such a person can also be considered as system configurator and system’s technical-supportive personnel. Administration-users usually install and deploy the MTA to production environment and handle the pre-configurations.

2.3.1.1 Experience computer users

Administrator-users are skilled computer users and their task is to do the initial system deployment configurations and help in situations when system has received an error it can’t recover from by itself. Administrator-users know the how the MTA system works and they also can perform system training for the supportive-users.

2.3.1.2 Distant presence

Administrator-users are usually technical persons from companies from where the MTA was acquired from. Other possibility is that administration-users is a third party technical person who has been hired and contracted to do the technical maintenance support for the system. In any case the administration-user is not expected to be near the deployed system.


2.3.2 Supportive-user characteristics

Supportive-user is a user who can help the senior end-user to use the MTA. Supportive users usually are care-house employees and they have options to adjust the MTA usage such as system font size and sound volume. It’s assumed that supportive users have at least small knowledge of computers but they will require small system training in using the MTA.

2.3.2.1 No experience with computing technologies at all

Supportive-users are usually local care-house employees and they are not required to be skilled in using or solving computer problems. However they are the usually only supportive users who can help the end-users in daily use of the system. They should not have too complex or too broad priviledges in the system.

2.3.2.2 Close presence

Supportive-users are nurses and other employees in the care house where the MTA is deployed in. Thus they have close presence to the system and the main end-users.

2.3.3 End-user characteristics

The main end-users are senior-class citizens with age of at least 60. Here are presented general and possible characteristics regarding the end-users. Not all of the characteristics apply to every end-user but they should be considered as a base for determining the requirements. Because end-users might have difficulties and disabilities in different areas the system shall be easily adjustable to address as many areas as possible.

2.3.3.1 No experience with computing technologies at all

End-users might not know what the computing or computers are at all and doesn’t know how to use applications or choose options. To address this problem the MTA shall have modes for each user type: end-user mode (UMOD), supportive-user mode (SMOD) and administration mode (AMOD). The administration mode can use classic computer paradigmas but the end-user and supportive-user modes shall only use case-specific paradigma. This case-specific paradigma shall not display any system configuration options and it’s an implementation of traditional newspaper usage (refered later as TNU paradigma).

2.3.3.2 Possibility of technophobia

It’s possible that some end-users might have technophobia meaning that they doesn’t want to work with technology they don’t understand or that they don’t trust in. Technophobia can be deflected by making the system passive, which shall be one major point of the TNU paradigma. Passive system means that the system won’t offer any services or options unless the user itself wants to access them by actively interacting with the system. Because of the passive style, each feature shall be easy to access with the multi-touch interface, in addition the system shall not ask any personal information from the user when in UMOD. The only identifier of the user will be something like fingerprint or palmprint which will be used for login when needed.

2.3.3.3 Possibility of impaired senses

It should be take account that some of the end-users might have impaired senses which should not be an obstacle to use the MTA. The MTA shall be designed to cover adjusting options to


address such situations.These adjusting option should be easy to access by supportive-user and the system shall remember the each adjustment state for each end-user.

2.3.3.4 Possibility of lack in locomotion

Some end-users might have lack in locomotion for example being in wheel-chair or having physical disabilities. To address this issues, the MTA shall not have fixed physical positioning as in regular hardware paradigmas. There shall be physical options to adjust the MTA’s physical values such as the position and angle.

2.3.3.5 Possibility of lack in fixed working space

Not all the end-users might be able to use the MTA in fixed working space, for example they are not able to interact with it in fixed position. This issues is addressed similar way as in 1.2.3.4.

2.3.3.6 Possibility of difficulties in memorizing and recalling

Some end-users might have difficulties in memorizing and recalling. Because of this classic login paradigma is not good way to handle personal indentification. This issue can be addressed by implementing finger-print reading which will handle the whole login procedure.

2.4 Operating Environment

The main target environment for the MTA is care-houses with senior citizens and supportive employees. It’s important for the system design to include environmental characteristics and constraints because they tend to differ from generic computer environments. Here are presented the major characteristics of such environment.

2.4.1 Care-house characteristics

Care-houses are usually departments where computing technology doesn’t play major part in resident’s life. In addition care-house department employees are usually not skillful technical oriented people which must be taken account in deploying the MTA to this environment.

2.4.1.1 Lack of space

It’s possible that care-houses doesn’t have much free space. MTA shall be designed that it won’t take too much space and that it can be installed to almost any place on regular building. In addition because there are no guarantee that the sytem could be installed in separate room the system shall have option for using wireless earphones to prevent distrubing other users.

2.4.1.2 Lack of internet bandwidth

It’s possible that care-houses doesn’t have decent internet connection which might be required to play rich internet multimedia seamlessly. If the multimedia can’t be played seamlessly it can confuse users and create technophobia as described above. To address this issue MTA shall be able to determine the level of richness multimedia which it can play seamlessly. If MTA can’t perform some multimedia seamlessly it won’t apply it at all. However, there is requirement that the environment shall have internet connection or the system can’t display the news.


2.4.1.3 Lack of skillful technical supporters

It’s possible that care-house employeers are not skillful in using or resolving problems related to computing technologies. MTA system shall be able to recover from minor errors by itself and it must be able to recover from major errors when rebooting the system by pressing a single button. The MTA shall notify any current user if it suffered major error but will only notify supportive and administration user when it has received minor error, when they login the system. If MTA has an error that it can’t recover from by itself, such as the lack of internet connection, it will notify any current user and give contact information from where technical help can be achieved.

2.5 Design and Implementation Constraints

The constraints at the designing time are that the needs of the end users may keep on changing so the designers must keep this in view and design the product in the way that it is easily updatable. The os may not support older hardware like keyboard and mouse’s so the designers must keep update with the entire hardware requirement so that it can work on the update of software. The hardware requirement may be like the capacity to store the data in hard drive and with timing the limitation of time to display the data and to open the display within the short period when the user touch the screen and some parallel operation like downloading the data as well as the user can read the data also. When the product is delivered to the customer than it should be designed in the easiest way so that they feel easy with using the system like keeping the bottoms and screen sixe big enough to enlarge the data with good pixelity provided and the tools used like display board and format used to present the data The system should be secure in the case when the news are being read by user and user profile are to be kept safe .

2.6 User Documentation

Author: pankaj jaiswal Date: 07-12-2009 Project ID: Multi touch application project Problem Description: May be with some user working in different Environment and with some backup system and Memory requirement Overall Design: This is a study based on the integration of FTIR multi touch technology with design to Produce a multi touch table .The process Includes FTIR structure related Testing, hardware technology and specification ; And the exterior design. Project Assumptions server should have a power backup as well And dependencies as a database backup. The MTA should be Compatible for working with Arch Linux OS.


User Interfaces: User interface through multi touch pad Implementation Details: the user touches the screen and activate the Screen and creates the gestures and the news Can be displayed Results: The user can have multi touch display for Reading the news without having the login Problem. Performance Evaluation: The system was more useful for different kind Of user like locomotors and the one who has The problem of disability and the one who Have the less memory remembrance so the system After going through different level of user Could be evaluated and the result was quite Good and acceptable with the user. References: web, http://www.billbuxton.com/multitouchOverview.html http://en.wikipedia.org/wiki/Multi-touch http://www.touchusability.com/multitouch/

2.7 Assumptions and Dependencies

Server should have a power backup as well as a database backup. The MTA should be compatible for working with Arch Linux OS. The system should work even if the hard drive is full. The commercial components can be taken as large backup system which can be brought in use for the this MTA system when the power backup is not enough and the external hard drive can be used for the larger storage of the data. The project can be affected if the components are not shared

3. System Features Here is list of features which are meant to address issues presented in user and environment classification and some additional but important system requirement features.

3.1 Traditional Newspaper Usage Paradigma

Traditional Newpaper Usage paradigma is used to give rules on how user interface shall be developed for the system. When refering the TNU in this requirement specification, it means the user interface of the system that is implemented using new design paradigm. TNU paradigm uses the traditional usage and usability factors of real-world newspapers as a base for design.

Description and Priority


These requirenets deals with the unique TNU paradigma. Each requirement has

priorization number from 1-5, in which 5 is the highest priority and 1 is the lowest priority. See section 1.2.1 for more detailed description of priorization.

Functional and non-functional Requirements

1001-01: All TNU controlling features shall be able to be performed with multi-touch

technology. P5

1002-01: TNU controlling features shall mimic traditional newspaper handling as much as

possible. P5

1003-01: TNU shall be applied to end-user mode. P5

1004-01: TNU shall be applied to supportive-user mode. P5

1005-01: TNU can be applied to administration-user mode. P3

1006-01: TNU shall be passive system, meaning that it shall not sugggest anything to

users, it will just wait for user to make actions. P5

1007-01: TNU shall have minimum amount of desktop paradigma’s GUI components,

such as menubars and popup menus. These components shall only be applied

in situation where there is no other natural way to present options. P5

1008-01: TNU shall have the whole display controlling areas in both lower corners of the

display. P5

1009-01: TNU shall be able to be controlled completely when using either lower corner

controlling areas. P4

1010-01: TNU shall make good use of multi-touch gesture-sensing. P5

1011-01: TNU shall not make any use of multi-touch pressure-sensing. P5

1012-01: Changing pages, activating multimedias and moving in the TNU shall be easy to

perform with multi-touch interfacing. P5

3.2 News and Multimedia

News and multimedia plays major role in newspaper application. When refering to News in this document, it means particularly formatted data that contains News information in Web-page format. News may contain text, pictures, links to another news and to other multimedia such as videos. When refering to multimedia in this document, it means all possible multimedia data that is associated with the News such as video of weather report.



These requirements deals with news and multimedia presentation and format. Each requirement has priorization number from 1-5, in which 5 is the highest priority and 1 is the lowest priority. See section 1.2.1 for more detailed description of priorization.


2001-01: The system shall require an internet connection to download news and

multimedia from server. P5

2002-01: News and multimedia can only be updated and downloaded from server. P4

2003-01: Downloaded news and multimedia shall be persisted to local hard-drive. P5

2004-01: When accessing news and multimedia that is already persisted to local hard-

drive system shall first make query from server if the data has changed. P3

2005-01: If data has changed since last download the data shall be downloaded again

until it’s displayed. P2

2006-01: The system shall display only data that it has downloaded to local hard-drive. P5

2007-01: The system shall have function to declare how much data it can download in

short time (less than 1 second) and according to it determine what kind of

multimedia data it will download from server. P3

2008-01: The system must be able to display news and multimedia seamlessly without

long (over 1 second) loading/waiting times. P3

2009-01: The system shall have built-in multimedia player that can play following

multimedia: video, sound and picture files. P5

2010-01: The system built-in multimedia player shall be able to play following video

fileformats: mp4, avi and swf. P4

2011-01: The system built-in multimedia player shall be able to display following picture

fileformats: jpeg, jpg, gif and png. P4

2012-01: The system built-in multimedia player shall be able to play following sound

fileformats: mp3, wav and wma. P4

2013-01: The system shall be able to display following web-page formats: HTML, DHTML

and XHTML. P5

2014-01: The system shall display news and multimedia files within web-page formats

described in requirement 2013-XX. P5

2015-01: Web-pages formats described in requirement 2013-XX shall have capability to

be styled with cascading stylesheet technique (CSS). P4


2016-01: Each news and multimedia files shall have date-tag information refering to which

real-world date the given news or multimedia is associated with. P5

2017-01: The system shall have capability to have always 500MB free space in it’s hard-

drive that is reserved for downloadable news and multimedias. P4

2018-01: The system shall use only up to 800GB for persisted news and multimedia.

When that capability is exceeded the system shall remove the news and

multimedia from hard-drive that has the oldest date-tag until the limits are met

again. P5

3.3 User Modes

There are three different user modes in the system. Each user mode represents different set of priviledges that the user can do with the system. Here are presented some major features and requirements that are applied to all different user modes. Each separate user mode has detailed features and requiremtns presented in sections 3.4 to 3.6.

Description and Priority These requirements deals with general user mode features. Each requirement has

priorization number from 1-5, in which 5 is the highest priority and 1 is the lowest priority. See section 1.2.1 for more detailed description of priorization.


3001-01: The system shall have three different modes: Administration-, supportive- and

end-user modes. P5

3002-01: Each mode shall have different priviledges on what configurations user can

change and alter. P5

3003-01: In every user mode user shall be able to display and browse news and

multimedia and other comments. P5

3004-01: Only the end-users have user-profiles in the system, which will contain system

properties for displaying and playing news and multimedia files. P5

3.4 Administration-user mode (AMOD)

Administration-user mode has he highest priviledges in using the system. Administration-user mode interface can be developed using any paradigma including the classical desktop paradigma. This mode is meant for administrative users who will configure the system.



These requirements deals with features associated with administration-user mode. Each requirement has priorization number from 1-5, in which 5 is the highest priority and 1 is the lowest priority. See section 1.2.1 for more detailed description of priorization.


4001-01: Administration-user mode shall be accessed with classic login system that has

username and password credential checking. P5

4002-01: In administration-user mode user shall be able to change any system options

and configurations. P4

4003-01: Administration-user mode can be implemented with classic computer

paradigmas. P3

4004-01: Additional administrator-user accounts can only be created and modified in

administration mode. P5

4005-01: Additional supportive- and end-user accounts can be created and modified in

administration mode. P5

4006-01: Administrator-user can logout the system and the system shall go to default end-

user state (with default user-profiles). P5

3.5 Supportive-user (SMOD)

Supportive-user mode has very limited priviledges in the system. Supportive-user mode shall be implemented like the end-user mode using the TNU paradigma. Supportive-user mode is meant for users who will support end-users in using the MTA. This mode has capabilities in adjusting end-user system properties such as the font-size and sound volume.

Description and Priority These requirements deals with features associated with supportive-user mode. Each

requirement has priorization number from 1-5, in which 5 is the highest priority and 1 is the lowest priority. See section 1.2.1 for more detailed description of priorization.


5001-01: Supportive-user mode can be accessed with login system where user fingerprint

identifies the user. P5

5002-01: In supportive mode user shall be able to adjust screen display and sound related

option such as font size and sound volume. P4


5003-01: Additional supportive- and end-user accounts can be created and modified in

supportive mode. P5

5004-01: While supportive-user mode is still in use and an end-user login the system, the

currently used user-profile will be persisted to end-user’s profile whose is about

the make login. P5

5005-01: When supportive-user login the system and the last login user was an end-user,

his/her profile will stay activated on the system. P5

5006-01: Supportive-user can logout the system and the system shall go to default end-

user state (with default user-profiles). P5

3.6 End-user Mode (UMOD)

End-users are the main users in the system, they are senior citizens with age at least 60 and they live in care house. End-user mode is for the end-users and it shall be implemented using TNU paradigma. The end-user mode has the least priviledges in using the system. In this mode the user may only browse news and multimedia. No adjustments or system configurations can be done in this mode.

Description and Priority These requirements deals with features associated with the main end-user mode.

Each requirement has priorization number from 1-5, in which 5 is the highest priority and 1 is the lowest priority. See section 1.2.1 for more detailed description of priorization.


6001-01: End-user mode shall be the default mode and doesn’t require any login. P5

6002-01: In end-user mode user shall not be able to adjust any configurations. P5

6003-01: No account modification can be made in this end-user mode. P5

6004-01: When new end-user tries to login the system and doesn’t have an account, a

new account will be created for the user. P5

6005-01: End-user mode can be accessed by any end-user who login the system by using

the fingerprint reader. P5

6006-01: End-users are not required to login the system to be able to use it. P5

6007-01: When end-user login the system, the system will load given user’s user-profile

into use. P5


4. External Interface Requirements

4.1 User Interfaces

Instead of using a mouse or stylus pen, multi-touch allows the user to interact with the device by placing two or more fingers directly onto the surface of the screen. The movement of the fingers across the screen creates gestures, which send commands to the device. Multi-touch requires a touch screen (screen, overlay, table, wall, etc.) or touchpad, as well as software that recognizes multiple simultaneous touch points, as opposed to the single touch screen (e.g. computer touchpad, ATM), which recognizes only one touch point. This effect is achieved through a variety of means, including: heat, finger pressure, high capture rate cameras, infrared light, optic capture, tuned electromagnetic induction, ultrasonic receivers, transducer microphones, laser rangefinders, and shadow capture http://en.wikipedia.org/wiki/Multi-touch For the tablet display, Cintiq, the multi-touch sensor has been prepared with a black tape mount. And some bottom for the user interface is kept on the corner to use the system comfortably.

4.2 Hardware Interfaces

Hardware requirements play important role in the MTA because it uses the state-of-art technology to produce new-generation application. Here is presented major hardware requirements regarding the MTA.

Description and Priority These requirements deals with features of the system hardware. Each requirement

has priorization number from 1-5, in which 5 is the highest priority and 1 is the lowest priority. See section 1.2.1 for more detailed description of priorization.


7001-01: Everything in the system shall be able to be controlled with multi-touch

technology. This is the default and primal way to control the system. P5

7002-01: System shall have classic keyboard and mouse supports (for cases when multi-

touch required configuration). P3

7003-01: System shall have wireless earphone support. P5

7004-01: System shall have built-in voice speaker. P5

7005-01: System shall have display that is 22 inches wide and 18 inches height. P5

7006-01: The display shall have screen resolution of 1920 x 1080 pixels. P5

7007-01: The display shall have built-in multi-touch capability using FTIR technology that

cover the whole display. P5

7008-01: Multi-touch technologys touch-resolution shall be 1920 x 1080 pixels. P5

7009-01: The system shall have Random Access Memory (ROM) of 8GB. P5

7010-01: The system shall have local hard-drive with capability of 1000GB. P5


7011-01: The sytem shall have fingerprint reader hardware which is used to login different

users. P5

7012-01: Wireless earphone technology must be able to activate/disactive with press of a

single button in hardware. P5

7013-01: The sytem shall have built-in support for two wireless earphones. P3

7014-01: The system shall have capability for one additional earphone technology as a

hardware plugin. P3

7015-01: The system shall have capability for one USB2.0 plugin. P3

7016-01: The system shall have capability for one HDMI plugin. P3

7017-01: To use the USB2.0 plugin, the user must be in AMOD. P2

4.3 Software Interfaces

There are some software and operational system requirements needed for MTA to enable flexible and robust solutions. Here is presented major software and operational system requirements regarding the MTA.

Description and Priority These requirements deals with the system software and operational system

associations. Each requirement has priorization number from 1-5, in which 5 is the highest priority and 1 is the lowest priority. See section 1.2.1 for more detailed description of priorization.


8001-01: Operational system for the MTA shall be latest stabile Arch Linux distribution. P5

8002-01: The multi-touch interface software shall be developed with MT4j technique. P5

8003-01: The file transfer between server and the system shall be implemented using

MULE ESB Enterprise technique. P5

8004-01: When keyboard is plugged in the system, the system shall ask for

administration-user login credentials. P3

8005-01: If administration login succeeds the system mode changes automatically to

AMOD. P2

8006-01: Operational system and any software within the system can only be updated

from USB2.0 plugin. P5

8007-01: The news and multimedia browsing application runs always in the system. P5


8008-01: The system shall have user profile system, in which the system preferences will

be store for each user separately. P5

8009-01: User profile system shall contain system preferences such as the used font-size,

sounds volume level and information about if the sound should be directed

automatically from earphones instead of built-in system speaker. P4

8010-01: Anytime at any state of the system when any user puts his/her finger on the

fingerprint reader his/her identification is declared. P5

8011-01: When user identification is declared as stated in requirement 8008-XX the

system shall automatically load user profile. P5

8012-01: Whenever user pofile is loaded the system shall go to news and multimedia

browsing application from any state. P5

8013-01: The news and multimedia browsing application shall be the only application

available when in UMOD or in SMOD. P5

4.4 Communications Interfaces

This section includes all the communication interface requirements such as the service providers and protocols used in MTA. Here is presented major communication requirements regarding server and services associated with the MTA.

Description and Priority These requirements deals with server and service features involved in the system.

Each requirement has priorization number from 1-5, in which 5 is the highest priority and 1 is the lowest priority. See section 1.2.1 for more detailed description of priorization.


9001-01: Server and news service provider is third-party company defined in server

specification document XYZBÅ. P5

9002-01: Server and service provider shall create schemas for the news and multimedia

transfer and representation and they shall be used. P5

9002-01: Server and service provider shall declare the MULE protocol for file and data

transferring and that declared protocol shall be used. P5


5. Other Nonfunctional Requirements

5.1 Performance Requirements

To help the developers understand the intent and make suitable design choices System performance manager shall be able to determine what data the system should request in one second .the system should be able to download the data in respect of time. To increase the performance of the system the timing factor should be main important paradigm for the system. Depending on the connection bandwidth and communication speed the system performance manager shall decide what data the system should request within given limited time and accordingly to this given time the performance of the system can be known which make developer easy to make the system. When browsing newest news with the system the downloading shall be done within the fraction of second to make end user feels to use this kind of features. Login the system shall take short period. It should take seconds of time to enter the page that the end user wants to visit.

5.2 Safety Requirements

Those requirements that are concerned with possible loss, damage, or harm that could result from the use of the product are like overloading data. The system must be able to download and fetch the data seamlessly from the provider and because not every internet connection bandwidth is the same, the system must be able to determine which data fetching would overload the department bandwidth too much so such a overloading data s should be ignored. There are some senior citizens who may not be familiar with the technical skills so some time they may not log out the system so which is nit the safety way to preserve his own profile. So for this kind of problem there should be system that alerts the user to log out to keep them working with safety site

5.3 Security Requirements

Administrative user shall have its own specific profile with unique user name and password so that it differentiate from different level of the user The data created by the system shall be kept in the database to keep the data safe. Database is a subsystem of the main system which manages the login procedures and contains all user-profiles and user privileged data. The most important user authentication shall do by finger prints recognition or the unique password. There shall be policies bounded in between the service provider and the system regarding the security.

5.4 Software Quality Attributes

Flexibility :-In context of user, it is most important to know what kind of flexibility the user

has with the system that they are using .In the case of MTA system the user

must have the flexibility to have login through the system just having the

recognition through finger print . End-user mode shall be the default mode and

doesn’t require any login. In end-user mode user shall not be able to adjust any


configurations so this kind of flexibility should be built in the system to make

user easy.

Maintainability:-the end user should also be provided with some kind help tool to let the

user to know to maintain the system.

Usability: - It is important to have reliable and repeatable evaluation techniques for

gestures. Without them we can't tell developers if their system is getting better

or compare two alternative implementations or products. Gestures are often

implemented using machine learning algorithms. The developer can train and

also evaluate the system using a very large dataset of gesture input that has

either been recorded or simulated. This kind of automated testing should ideally

be done as part of algorithm development. You don't always need to implement

gestures using learning algorithms. Assume the developers have done their job

and the user is a usability person asked to evaluate the gestures and give

feedback. Maybe the developers have a dataset of gesture input data but

they're not sharing. Here are some of the scenarios for when a usability test of

gestures is useful: 1) Formative usability tests to help developers know if and

how their algorithm improving or not. These can also evaluate the gestures

within a realistic context -- evaluate whether the gestures work well in specified

applications, whether the feedback and actions performed by the gestures are

working appropriately.2) Summative and competitive tests. Document the

performance of the gestures for future reference. Compare the gestures on

system A and system B, where the systems might have different hardware,

firmware, or software, may be running different end-user applications, may have

touchpad’s of different sizes or shapes, have different surface textures or

different bezels. http://www.touchusability.com/multitouch/

Correctness:-The system should be correct with the data that is to displayed on the multi

Touch screen board so that user don’t get difficulty in reading with the news.

Verifiable.-The MTA system should be verified before bringing it into the hand of user. It

Should go through some testing process so that it can be error free.

Portable:-The system display pad should be easy enough to carry so that user can carry it

With them like the different iPhones which has this kind of facility.

Some to consider are: adaptability, availability, correctness, interoperability,

maintainability, portability, reliability, reusability, robustness, testability, and


usability. Write these to be specific, quantitative, and verifiable when possible.

At the least, clarify the relative preferences for various attributes, such as ease

of use over ease of learning.>

6. Other Requirements This section contains all the other requirements and documents associated with this requirements specification document.

Appendix A: Glossary Here are presented list of abbreviations used in the requirement specification Abbreviation Description

MTA Multi-touch Application. Complete computing system that offers an application and uses multi-touch technology for implementing user interface.

TNU Traditional Newspaper Usage paradigma. A case-specific paradigma for how the newspaper application can be presented and controlled in a multi-touch applicaton system.

AMOD Administration Mode. System mode for MTA which has the most advanced priviledges in configuring the system.

SMOD Supportive-user Mode. System mode for MTA which has prviledge to adjust some system properties such as the font size and sound volume.

UMOD End-user Mode. System mode for MTA which has only priviledge to view and browse application content.

Classic desktop

paradigma

This is the dominant paradigma on how graphical user interfaces are implemented in modern day computers. Such implementation involves for example windowing, popup menus and menubars.

Classic login system

paradigma

This implementation usually involves combination of username and password credential checking. Some senior citizen might have difficulties in memorizing and recalling such an information which makes it bad practise for this system.

FTIR Frustrated Total Internal Reflection. Technology that allows the multi-touch capabilities.

Appendix B: Use Case Models This section contains use case models for the system. Each use case models are identified with case identifier (CID) and a use case diagram is provided for each use case.

Use Case: 100-01 – Login and end-user profiles

Login function work differently for each user type. Supportive- and end-users can login the system with fingerprint reader while administrator-user can login only by pluggin in and using the physical separate keybord.When administration- or supportive-user login their priviledges will only be loaded and set in use, which will determine which options they can configure in the system. When


end-user login they will have no priviledges to configure any options but their user profile will be loaded and set in use during the login procedure. End-user profile will determine how the news and multimedia browser application will display and play its content (ie. what’s the font-size etc). Logged in supportive-users can configure end-user’s user profile. The diagram of this use case is presented in figure 1.

Actors

Administrator-user: User who has administrative priviledges in system. He has the option to change any system configuration and usually is system’s technical contact person from company which provided the system. Supportive-user: User who has priviledges to change and adjust end-user profiles. These users are usually employees at the care-house department. Their mission is to help end-users when they need help. End-user: The main users are senior-class citizens with age at least 60 and that live in care-house. These users can only use the sytem to browse news and play multimedia. Database: Database is a subsystem of the main system which manages the login procedures and contains all user-profiles and user priviledge data.

Assumptions and constraints

Although each login will force previous users to logout, the user-profile will stay on the system, unless the new login user was another end-user, in which case his/her user-profile will override the user-profile. Below is presented situation how supportive-user can adjust end-user’s profile: Before supportive-user can actually change any user-profiles, the end-user must login the system. During the login end-users user-profile will be loaded and activated. After the end-user login the supportive-user can login, and now the last login end-user profile is available in the sytem for adjustment. After the supportive-user have adjusted the user-profile for the end-user, the end-user will have to login the system again to verify and persist those adjustments to his profile. When end-user will login while supportive-user is still login, the currently used user-profile will be persisted to the end-user’s profile before his login procedures.

Non-functional requirements

Fingerprint reader associated with the database can identify the user within 100 millseconds with 95% accuracy

Scenarios

End-user A login the system. He puts his finger on the fingerprint reader and the database will manage his login. During the login end-user A’s user-profile will be loaded in use and previous login user will be forced to logout. After successful login the end-user A tries to read today’s news but the font is too small for him to see and he has forgot his reading classes. End-user A asks supportive user’s (nurse’s) help. Supportive-user B (local nurse employee) comes to help the oldman and puts her finger to fingerprint reader. Her login succeeds, now the oldman is logout and supportive-user is login, but oldman’s user-profile still stayes active


in the system. Login supportive-user can now easily adjust the font-size by using gestures on the multi-touch surface and when the font-size is good sized again, the oldman must put his finger on the fingerprint reader and the adjusted profile will be persisted to his user-profile, which will be loaded in the use due to his login.

Error cases

If supportive-user login the system and adjust some properties for an end-user A, but the end-user doesn’t login the system after the adjustments there is chance for human-error. In this situation end-user will leave the system and supportive-user forget’s the logout, now adjusted end-user A’s profiles are still in use with the system and it’s in state of supportive-user. When new end-user B comes to system and login, the end-user A’s profiles will be persisted to end-user B’s profiles and end-user B’s own profile will be lost.

Figure 1. Login and user-profile use case diagram

Use Case: 200-01 – Request news from provider


When browsing newest news with the system the news must be requested from service provider using internet connection. The system must be able to download and fetch the data seamlessly from the provider and because not every internet connection bandwidth is the same the system must be able to determine which data fetching would overload the department bandwidth too much. The data that would cause overloading are ignored in the downloading. The system must be also able to manage its hard-drive space. If it has downloaded too much data to it’s local hard-drive, it must be able to remove the oldest data to get necessary space available. The diagram of this use case is presented in figure 2.

Actors

Administrator-user: User who has administrative priviledges in system. He has the option to change any system configuration and usually is system’s technical contact person from company which provided the system. In addition to configurations, administrator-user can browse news and multimedias. Supportive-user: User who has priviledges to change and adjust end-user profiles. These users are usually employees at the care-house department. Their mission is to help end-users when they need help. In addition to supportive role, supportive-user can browse news and multimedias.

End-user: The main users are senior-class citizens with age at least 60 and that live in care-house. These users can only use the sytem to browse news and play multimedia. Service provider: Service provider is a company server that provides all the news and multimedias for the MTA system. System performance manager: This is a subsystem of an MTA. The system performance manager can determine what performance the system can handle. For example according to connection bandwidth and communication speed with the service provider the performance manager can determine what kind of data can be downloaded to local system seamlessly. System performance manager will determine what data will be ignored when requesting data from service provider. System performance manager will also handle local hard-drive space managing tasks.

Assumptions and constraints

Multimedia data is HD quality but it’s compressed. Typical news and comments will be in JSON format during the transfer. If the system has persisted news data already to local hard-drive, but the content of the data has changed, the new requested data will overwrite the previous same news data in local hard-drive.

Non-functional requirements

System performance manager shall be able to determine what data the system should request in one second. In addition System performance manager should keep 500MB of space always free for download data and remove the oldest data automatically when there is not enough free space left.

Scenarios

When any MTA user wants to browse news the sytem will check if the given news are already persisted to local hard-drive. The system will also check if the news content has


changed since the persisting date. If the news are not persisted at all or the content has changed the system will request this new data from service provider. In case of requesting new data the system perfromance manager will first check how much and what kind of data is available in server regarding the given news. The system perfromance manager will also check the current connection bandwidth speed and evaluate what data it should and can download. At this point the system performance manager will also check the free space in local hard-drive and make procedures to make it possible to download the data. After all evaluation is done the data is requested from server, persisted to hard-drive and rendered in display. If data was already persister in the local hard-drive and no changes has occurred in the content the data will be loaded from the hard-drive and rendered in display.

Error cases

Error case can happen when system perfromance manager has performed checking how much and what kind of data is available from server and goes to state to check the bandwidth connection. If the data will change on the server during system performance manager’s the bandwidth test, the requested data can break the seamless downloading if the new revised data happens to be more than what was checked.

Figure 2. Request news from provider use case diagram


Appendix C: Vision Document Browse news and multimedia Users can rotate their display horizontally. Scrolling is done by swiping a finger across the screen. It should be fast enough and display the data as fast as possible and should be easy to do the task. The data to be displayed should have different selection language and should get magnify with the data to make it easy and clear to read. 2) Check if there any is enough hard drive space free in system This condition should be checked so that new user can be logged in to browse the new and play the media. So the checking for free space in the system should be done .If there is oldest data than remove it from the hard drive if there is not enough space .the checking should be done that how much data is provided so that current news can be initiated and the multimedia request too 3) Identify user login. If there is anybody already logged so logout earlier user .even we can use finger print reader to identify the user and then load user profile.

Appendix D: Test Cases 1) Traditional newspaper usage paradigm All TNU features shall be able to work with multi touch technology if it is applicable and easy for the end user mode, supportive user mode, and administrative user mode TNU should be passive .Thus the user should be allowed to use some blocking command so that it can have control and doesn’t suggest anything to user without its permission. It shall have whole display controlling area. If the user can increase the font size and make expand the news than it can have control in some part of the display. The system should have capability to work with enough space and should have capacity of 500 mb of space to download the news. It should automatically remove the old news and load the recent news for making the free space available. To download the news and multimedia from the server the user should have internet connection with fast accessibility with larger bandwidth and should have enough space in hard drive.

7. Contribution For The Project This requirements specification document and all associated documents was produced for Joensuu University’s Requirements Engineering course in 2009. Contributors are Aki Heikkinen ([email protected]) and Pankaj Jaiswal ([email protected]). Both contributors are students in Department of Computer Science and Statistics. Heikkinen has contributed following material for the project: Chapter 1, chapters 2.3 – 2.4.1, chapter 3, chapters 4.2 – 4.4, and use case models 100-01 and 200-01. Jaiswal has contributed following material for the project: Chapters 2.1 – 2.2, chapters 2.5 – 2.7, chapter 4.1, chapter 5, Visio-document and all test-cases.

Documents

Software Requirements Specification Multi-touch …cs.joensuu.fi/~akheikki/RE/Project 2 - Multi-Touch Newspaper SRS.pdf · Software Requirements Specification for Multi-touch Newspaper