Software Requirements
Specification
for
Multi-touch Newspaper
Version 1.0 approved
Prepared by Aki Heikkinen and Pankaj Jaiswal
Joensuu University
16.12.2009
Copyright © 2002 by Karl E. Wiegers. Permission is granted to use, modify, and distribute this
document.
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.
Software Requirements Specification for Multi-touch Newspaper
Page 2
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
Software Requirements Specification for Multi-touch Newspaper
Page 3
INPUT FROM MULTI-TOUCH
SCREEN
TOUCHLIB
GESTURE EVENT
APPLICATION
MULTI TOUCH
EVENT
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.
Software Requirements Specification for Multi-touch Newspaper
Page 4
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 carehouses. 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 technicalsupportive 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.
Software Requirements Specification for Multi-touch Newspaper
Page 5
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 endusers 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 enduser 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
Software Requirements Specification for Multi-touch Newspaper
Page 6
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.
Software Requirements Specification for Multi-touch Newspaper
Page 7
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:
Date:
Project ID:
pankaj jaiswal
07-12-2009
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
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.
Software Requirements Specification for Multi-touch Newspaper
User Interfaces:
Implementation Details:
Results:
Performance Evaluation:
References:
Page 8
User interface through multi touch pad
the user touches the screen and activate the
Screen and creates the gestures and the news
Can be displayed
The user can have multi touch display for
Reading the news without having the login
Problem.
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.
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
Software Requirements Specification for Multi-touch Newspaper
Page 9
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.
Description and Priority
Software Requirements Specification for Multi-touch Newspaper
Page 10
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.
Functional and non-functional Requirements
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 harddrive 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
Software Requirements Specification for Multi-touch Newspaper
Page 11
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 harddrive 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.
Functional and non-functional Requirements
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.
Description and Priority
Software Requirements Specification for Multi-touch Newspaper
Page 12
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.
Functional and non-functional Requirements
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 enduser 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 enduser 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.
Functional and non-functional Requirements
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
Software Requirements Specification for Multi-touch Newspaper
Page 13
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 enduser 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.
Functional and non-functional Requirements
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
Software Requirements Specification for Multi-touch Newspaper
Page 14
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.
Functional and non-functional Requirements
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 multitouch 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
Software Requirements Specification for Multi-touch Newspaper
Page 15
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.
Functional and non-functional Requirements
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
Software Requirements Specification for Multi-touch Newspaper
Page 16
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.
Functional and non-functional Requirements
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
Software Requirements Specification for Multi-touch Newspaper
Page 17
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
Software Requirements Specification for Multi-touch Newspaper
Page 18
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
Software Requirements Specification for Multi-touch Newspaper
Page 19
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 This is the dominant paradigma on how graphical user interfaces are
desktop implemented in modern day computers. Such implementation involves for
paradigma example windowing, popup menus and menubars.
Classic This implementation usually involves combination of username and password
login system credential checking. Some senior citizen might have difficulties in memorizing and
paradigma 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
Software Requirements Specification for Multi-touch Newspaper
Page 20
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 endusers when they need help.
End-user: The main users are senior-class citizens with age at least 60 and that live in carehouse. 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 enduser 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
Software Requirements Specification for Multi-touch Newspaper
Page 21
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 supportiveuser. 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
Software Requirements Specification for Multi-touch Newspaper
Page 22
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 harddrive, 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 endusers 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 carehouse. 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 harddrive, 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
Software Requirements Specification for Multi-touch Newspaper
Page 23
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
Software Requirements Specification for Multi-touch Newspaper
Page 24
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
(akheikki@cs.joensuu.fi) and Pankaj Jaiswal (pjaiswal@cs.joensuu.fi). 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.