Transcript SYSTEM DESIGN: Exercise

Principles of
Engineering System Design
Dr T Asokan
[email protected]
System Design Examples
InSeKTs
Institute Service Kiosk Terminals
INTRODUCTION
• InSeKTs – (Institute service kiosk terminals) is
an initiative of IITM’s e-service enhancement
program.
• IITM proposes to introduce these terminals at
strategic locations to help IITM community and
visitors with various services.
• It would serve as a means for providing support to a
user when he/she is in the institute. The support will
have 2 major components –
Information component and service component.
• Information component will provide the user with
information about institute, Chennai, people at IITM,
location of various buildings, location and waiting time
for buses etc. as desired by the user.
• Service component will provide the user with
services like internet, fax, pay telephone, printer etc.
• The mission of the InSeKTs is to make the user feel
hospitable.
It should be able to make an outsider feel
independent in the campus. It should also aid the
IITM community by providing easy assistance. It
should deliver easy info and should be quick and user
friendly. It should provide emergency assistance when
needed.
MISSION OBJECTIVES
• Online access to various services (Academic,
Administrative, general) to students, staff and
visitors with various levels of accessibility.
• Information regarding location of class rooms,
maps and navigational information within the
campus.
• Utility services like telephone, fax, e-mail, printing
etc.
• Provide weather data, train/flight schedule/timing
etc.
• Provide information about Chennai, maps of
Chennai and nearby places, bus, train and road
routes in and out of Chennai.
• Provide information about location and waiting time
for institute bus.
• Provide information about people in IITM like
address, telephone number, email id etc. for
outsiders.
GENERAL REQUIREMENTS
• InSeKTs should provide real-time services,
information and assistance to IITM
community/visitor 24 hours a day 7 days a week
for the following events:
• User needs information, assistance.
• User needs emergency help, services.
• User needs utility services like telephone, fax,
printout and internet.
• User needs locations and navigational aid in and
around Chennai.
• User needs information about Chennai.
SPECIFIC REQUIREMENTS
• The InSeKTs system shall have an availability of
0.99.
• The InSeKTs system shall connect to GPS satellite
within 1 min of switching on.
• The InSeKTs system shall connect to internet
within 1 min of switching on.
• The InSeKTs system shall show location of
institute bus within 2 metre of error.
• The InSeKTs system shall provide for Telephone
service for local and emergency calls.
• The InSeKTs system shall provide railways/airways
schedule and status accurate to 0.1% error.
• The InSeKTs system shall provide fax and printout
service with an availability of 0.95.
• The InSeKTs system shall provide intranet services
for IITM community.
• The InSeKTs system shall have a Mean-TimeBefore-Failure of 20,000 hours and a Mean-Time-ToRepair of 5 hours.
• The InSeKTs system shall provide weather forecast
data in coordination with live news channels.
•The InSeKTs system shall provide information about
Chennai and places in a radius of 10km.
•The InSeKTs system shall provide information about
local transport (bus routes, train, road maps) in
Chennai.
•The InSeKTs system must provide maps and
navigation about IITM to visitor.
S ystem Engine ering, VE E diagram
M ission S tatem ent
Users W ants & N eeds
+ em ergency
requirem ents
U ser aid, user
satisfaction,help
Custom er F eedback, U ser E xperience,
Needs
Feasibility F eedback
M achine level inputs
User, powe r, m aintenance,
interfaces , G P S, internet,
intranet
Requirem ent
cascade
Custom er requirem ents
Trial,
Usage
Update,
Upgrade
Feasibility F eedback
M achine level requirem ents
Charecteristic s, attributes,
specifications
R equirem ent
c asc ade
Verific ation,
production, testing
Feas ibility Feedback
S ystem /Subsystem
S ys tem and subsystem design
requirem ents and specifications
S ystem Verification and
prototy ping
Feasibility Feedback
Requirem ent
cascade
Part/c om ponent fabrication and
Verification
P art/C om ponent
D es ign spec ifications
Airways service
Satellite GPS
And weather
Railway
service
Supplier
Transmission
Customer
support
Telephone Printer Fax
User
Internet
Server
and
Database
OPERATIONAL SCENARIOS
1. Visitor uses InSeKTs to find directions in IITM
campus
- Visitor switches device on
- Feedback device is switched on
- Feedback requests type of user (visitor/IITM
community)
- User selects visitor option
- Selects option to get directions and locations of
various buildings in IITM campus
- Feedback device shows current location and
important landmarks in IITM campus
- Requests directions from one location to another
- Feedback received on clear directions from one
place to another
- Feedback on option to print map of IITM campus
- User selects option to print map
- Feedback map with desired directions is printed and
important landmarks highlighted
- User is satisfied and log off
- customer logged out .
-Feedback user has been successfully logged out of
the network
2. User uses InSeKTs for accessing Internet
- User switches device on
- Feedback device is switched on
- Feedback requests type of user (visitor/IITM community)
- User selects IITM community option
- Feedback device requests username and password
- User enters username and password
- Feedback user is logged in if password is correct
- User selects internet option
- Feedback that internet has been connected
- User uses internet as per desired
- Feedback is given accordingly
- User logs out when finished
- Feedback user has been successfully logged out of
the network
3.
User uses InSeKTs for making a phone call
User switches device on - Feedback device is
switched on – User selects telephone option –
Feedback telephone is activated – Feedback
telephone asks the user to insert coins – user
enters coins – Feedback dial tone is switched on
– user dials number – feedback sound of
numbers being dialled and call being connected
– user talks on the phone
– feedback voice of person at other end – feedback
that 1 minute is about to finish by beeping sound –
user inserts additional coins –feedback minute
extended – user finishes call and places back
receiver – feedback telephone is switched off and call
is disconnected – user switches off device – feedback
device is switched off.
4. User uses InSeKTs for sending or receiving a
fax document
User switches device on - Feedback device is
switched on – User selects Fax option – Feedback
Fax is activated – user selects whether to sends or
receive fax – feedback, if to send file machine
requests document, if to receive file, machine
requests connection number of phone from which to
receive the fax – user inserts document and
destination fax number in case of sending file, and
enters fax number in case of receiving the fax
– feedback machine responds accordingly, sends fax
to desired machine or receives fax from desired
machine – Feedback that fax has been received and
printed or delivered according to function selected –
user disconnects the fax machine – fax machine
switched off – user switches of device – device
turned off.
5. User uses InSeKTs for acquiring information
about Railway/Airway status/schedule
User switches device on - Feedback device is
switched on – User selects Railway/Airway option –
Feedback Railway/Airway is activated. User selects
status/schedule option – status/ schedule is activated
accordingly – user requests schedule – feedback
enter train/Aeroplane details – feedback schedule is
displayed accordingly – user requests reservation
status of his/her ticket – feedback on connecting with
server and reservation status is displayed – user is
satisfied and switches off device – device switched
off.
6. User uses InSeKTs for printing Data
User switches device on - Feedback device is
switched on – User selects printing option –
Feedback printer is activated – Feedback printer asks
the user to input data – user gives data– Feedback
asks for number of copies – user enters desired
number – feedback type of printing/printer – user
selects desired type of printing –feedback printing
on progress –feedback printing data is done – user
switches off device – feedback device is switched off.
7. User uses InSeKTs to know about weather
The user switches on the device- feedback that the
device is turned on -user enters the required datauser selects the weather report option- feedback
connecting to the facility - feedback to select the
place- user selects the desired place - feedback that
the data is being processed- feedback that the
weather report is ready- user selects the option to
view - user receives all the weather data- user exists
the application-feedback device turned off.
1.
T o g e t d ir e c tio n s in IIT M c a m p u s ( v i s ito r )
G PS
In S e K T s
USER
S w itc h o n d e v ic e
D e v ic e s w itc h e d o n
R e q u e s t ty p e o f u s e r
v is ito r
B u ild in g s a n d d ir e c tio n s in IIT M c a m p u s
IIT M m a p a n d im p o r ta n t la n d m a r k s
R equest m aps
M a p s u p lo a d e d
C u r r e n t lo c a tio n
S e le c t d e s tin a tio n
D e s tin a tio n s e le c te d
P o s s ib le r o u te s s h o w n
O p tio n to p r in t m a p
P r in t m a p
M a p p r in te d
S w itc h o ff d e v ic e
D e v ic e s w itc h e d o ff
R e q u e s t c u r r e n t lo c a tio n
C u r r e n t lo c a tio n u p d a te d
R e q u e s t p a th to d e s tin a tio n
P a th c a lc u la te d a n d in d ic a te d
2. To Access Internet
USER
InSeKTs
Switch on device
Device switched on
Request type of user
IITM community
Request username and password
Username and password entered
Authenticate username and password
Request internet connection
Internet connection granted
Request internet connection
Authenticate username and password
Provide internet settings
Connection and bandwidth granted
Use internet
Necessary feedback as desired
Log out
User logged out
Switch off device
Device switched off
Logout and break connection
Server
3. To make a Phone Call
USER
InSeKTs
Switch on device
Device switched on
Request telephone service
Telephone service switched on
User lifts receiver
Message to insert coins
Coins inserted
Dial tone activated
Numbers dialed
Sound of numbers being dialed
Talk on phone
Voice through receiver
Insert additional coins
Time extended
Replace receiver
Call disconnected
Switch off device
Device switched off
Telephone exchange
Request telephone services
Telephone services provided
Service disconnected
4. InSeKTs - Originating Requirements Document
4.1 System Over View
The InSeKTs system shall provide information
and services, for personal and commercial use, to
its user about the campus of Indian Institute Of
Technology- Madras. It shall provide information
reliable more than 95% of the times and can cater
to at-least 5 and no more than 20 centers around
the campus with each center managing upto 50
users at a time.
4.2 Applicable Documents: The system shall adhere
to standard industrial database standards including
the following minimum ones
4.2.1. SQL-92
4.2.2. SQL-1999
4.2.3. JDBC
4.2.4. SQLJ
4.2.5 ADO.NET Interface
4.2.6. JavaÔ Database Connectivity (JDBC)
4.2.7. Open Database Connectivity (ODBC)
4.2.8. Other standard codes and standards by
ANSI, INCIT, IEEE, ISO, IEEE for data security
and organisation & communication.
4.3 Operational Phase Requirements
4.3.1. Input/Output Requirements
4.3.1.1. Input Requirements
4.3.1.1.1. Requirements for inputs from users
4.3.1.1.1.1. The system shall receive
99% of queries from users.
4.3.1.1.1.2. The system shall receive
99.99% emergency requests from users.
4.3.1.1.1.3. The system shall receive 95%
calls for bus timings and routes.
4.3.1.1.1.4. The system shall receive 99%
requests for directions.
4.3.1.1.1.5. The system shall receive 99%
requests for utility information.
4.3.1.1.1.6. The system shall receive 98%
requests given asked via phone, internet,
sub-centers, etc.
4.3.1.1.1.7. The System shall accept
requests 99% of the times.
4.3.1.1.2. Requirements for inputs from maintenance
personal
4.3.1.1.2.1. The system shall receive 70% of
all routine maintenance calls within 5 hrs.
4.3.1.1.2.2. The system shall receive 99%
of all diagnostic signals.
4.3.1.1.2.3. The system shall receive
99.9% of requests for diagnostic log files.
4.3.1.1.2.4. The system shall receive 60%
all repairs within 4 hrs.
4.3.1.1.2.5. The system shall receive
99.99% of all data during test runs irrespective of
the type of requests.
4.3.1.1.3. Requirements for Inputs from Primary Server
4.3.1.1.3.1. The system shall receive 95%
queries from primary server during peak load and
99.9% otherwise.
4.3.1.1.3.2. The system shall receive regular
updates from the server 99% of the times.
4.3.1.1.3.3. The system shall receive requests
from the main server 10% of the times in stand alone
mode. These requests will be used to regulate this
mode.
4.3.1.1.3.4. The system shall receive 99.99%
of ON/OFF calls from the server.
4.3.1.2. Output Requirements
4.3.1.2.1. Output requirements to User
4.3.1.2.1.1. The system shall provide a
minimum information to the user within 10 sec
95% of the time. Design Goal is 5 sec.
4.3.1.2.1.2. The system shall provide
the user with a network time out error or failure
feedback in case of failure of 4.3.1.2.1.1.
4.3.1.2.1.3. The system shall
continually display emergency routine(s) when
necessary.
4.3.1.2.1.4. The system shall provide services even
during periods of maintenance.
4.3.1.2.1.5. The system shall show real
time usage traffic and information flow rates to the
user.
4.3.1.2.1.6. The system shall provide
feedback 99.99% of the time to acknowledge query
acceptance to the user.
4.3.1.2.1.7. The system shall continually show its
state of connectivity with the primary server, internet,
database and satellites for the user's convenience.
4.3.1.2.1.8. The system shall show estimated
recovery time in case of system failure
or maintenance or both.
4.3.1.2.1.9. The system shall give both hard-copy
and soft-copy responses to the user query.
4.3.1.2.2.Requirements for output to maintenance
personal
4.3.1.2.2.1. The system shall provide diagnostic
response that are correct 99.99% based on
diagnostic signals.
4.3.1.2.2.2. The system shall provide test results that
are 99.9% correct.
4.3.1.2.2.3. The system shall immediately give
malfunction signals that are correct 98% of the
times.
4.3.1.2.2.4. The system shall provide feedback to
the personal 99% of the time to acknowledge their
request.
4.3.1.2.3. Requirements for output to the
Main Server
4.3.1.2.3.1. The system shall provide output
to server calls 99.9% of the times.
4.3.1.2.3.2. The system shall regularly
update the database 99.99% of the times.
4.3.1.2.3.3. The system shall report of
performance drops and traffic data to the
server once every ten minutes.
4.3.1.3. External Interface Requirements
4.3.1.3.1. Electric Power. The system shall
receive power from the location's main power
supply using ISO or BIS standard
connections.
4.3.1.3.2. Emergency Phone. The system
shall have an emergency phone with limited
outgoing ability to be used in case of
emergencies.
4.3.1.3.3. GPS. The system shall have direct
access to GPS satellites to improve data
transfer rates.
4.3.1.3.4. Backup Power. The system shall have a
backup power unit in case of power failure.
4.3.1.4. Functional Requirements
4.3.1.4.1. The system shall accept user requests and
provide feedback.
4.3.1.4.2. The system shall provide up-to-date and
accurate data.
4.3.1.4.3. The system shall provide reliable
connections and data transfer rates.
4.3.1.4.4. The system shall enable effective
4.3.2. System-wide and Technological requirements
4.3.2.1. Technology Requirements
4.3.2.1.1. GPS. The system shall
require accurate GPS tracking system.
4.3.2.1.2. Internet. The system shall
require fast and high bandwidth
internet facilities.
4.3.2.2. Suitability Requirements
4.3.2.2.1. Government Regulations
4.3.2.2.1.1. The system shall cater
to all the relevant fire and safety
codes.
4.3.2.2.1.2. The system shall adhere to all
the Central, State and local Laws in place.
4.3.2.2.2. The system shall have an MTBF of greater
than 10 year. The design goal is 17 years. Failure is
defined to be a complete inability to cater to any
queries of the user.
4.3.2.2.3. The elevator system shall have an MTTR
of less than 5 hours. The design goal is 3 hours.
Repair means the system is returned to full
operating capacity.
4.3.2.3. Cost Requirements. The system shall run at
less than Rs.5000 per month.
Design goal is Rs.3000 per month.
4.3.2.4. Schedule Requirement. The system shall
have an expected life expectancy of at least 30
years.