Download General Template for Informational Services

Application Requirements Document
Disaster Management Service (Basic)*
General Template for Informational Services
How to Use this Document
This document specifies requirements for the selected service. These requirements go beyond the high level
planning information and specify detailed information that can be used to better understand the system and also as a
means of communications between the system analysis and system development teams.
Table of Contents










Definitions and Terms
0. Overview of Service Disaster Management Service (Basic)*
1. Overview and Business Drivers
o Business Needs (edit and modify to fit your needs)
2. background Information
3. Application Functional Requirements
4. Information Models (Use Cases, Class Diagrams, Sequence Diagrams)
5. Logical Architecture (Application Pattern)
6. Architecture and Integration Requirements (General)
o Distributed Architecture Requirements
o Interface/Integration Requirements
7. Architecture and Integration Requirements (Specialized based on the Interview)
8. Operational Requirements (Generic)
o Security/Permission Requirements
o
o
o


Performance Requirements
Hardware Requirements
Software Requirements
9. Vendor Support Requirements
o Application Service Provider (ASP) Support
o Back Up and Maintenance Support
o Documentation Support
o Training Support
10. SOA Considerations
o Suggestions
Definitions and Terms
ACL
ACM
AI
AIA
API
ASP
ASP
ATM
ATM
B2B
B2C
B2E
B2G
BREW
BSP
CAD
CAM
CBX
CCITT
CDMA
CDPD
CGI
CIO
Authorized Control List
Association of Computing Machinery
Artificial Intelligence
Application Integration Architecture
Application Programming Interface
Application Service Provider
Active Server Pages A Microsoft technology for building server
side code
Asynchronous Transfer Mode a packet switching Technology
used typically in high data rate networks
Automatic Teller Machine used in banking
Business to Business
Business to Consumer
Business to Employee
Business to Government
Binary Runtime Environment for Wireless
Business System Planning
Computer Aided Design
Computer Aided Manufacture
Computerized Branch Exchange
Comit Consultatif Internationale de Tlgraphique et Tlphonique
(The International Telegraph and Telephone Consultative
Committee)
Code Division Multiple Access
Cellular Digital Packet Data
Common Gateway Interface - A Web gateway technology
Chief Information Officer
CORBA
COTS
CPU
CRM
CSF
CSMA/CD
DBMS
DCOM
DDBMS
DDL
DDTMS
DML
DOD
DSL
DTM
DTMS
EAI
EB
EC
EDI
EJB
ERP
ETSI
FCC
FDDI
FDM
FSO
FTP
GUI
I/O
IDL
IEEE
IMS
IP
IPC
IRM
ISDN
ISO
ISP
IT
Common Object Request Broker Architecture
Commercial Off-The-Shelf
Central Processing Unit
Customer Relationship Management
Critical Success Factors
Carrier Sense Multiple Access/Collision Detect
Database Management System
Distributed Component Object Model
Distributed Database Management System
Data Definition Language used in database management
Distributed Data and Transaction Management System
Data Manipulation Language
Department of Defense
Digital Subscriber Loop
Distributed Transaction Manager
Distributed Transaction Management System
Enterprise Application Integration
Electronic Business
Electronic Commerce
Electronic Data Interchange
Enterprise Java Beans
Enterprise Resource Planning
European Telecommunication Standards Institute
Federal Communications Commission
Fiber Distributed Data Interface
Frequency Division Multiplexing
Free Space Optics
File Transfer Protocol
Graphical User Interface
Input/Output
Interface Definition Language used in CORBA and other
distributed object middleware services
Institute for Electrical and Electronic Engineers
Information Management System - IBM DB/DC system on
mainframes
Internet Protocol
Interprocess Communication
Information Resource Management a management methodology
Integrated Services Digital Network
International Organization for Standardization
Internet Service Provider
Information Technology
ITU
ITU-T
International Telecommunications Union
International Telecommunications Union - Telecommunications
Services Sector
J2EE
Java Version 2 Enterprise Edition
J2ME
Java Version 2 Mobile Edition
JDBC
Java Database Connectivity
LAN
Local Area Network
LDBMS
Local Database Management System
LLC
Logical Link Control
LMDS
Local Multipoint Distribution Service
LU
Logical Unit - an endpoint in the IBM SNA environment
MAC
Medium Access Control
MAN
Metropolitan Area Network
Mbps
Million bits per second
MMIT
Microsoft Mobile Internet Toolkit
MOM
Message Oriented Middleware
MVS
Multiple Virtual System - operating system on IBM's
mainframes
NBS
National Bureau of Standards
NFS
Network File Services - SUN Microsystem's File System for
Networks
NIST
National Institute of Standards and Technology
OAG
Open Application Group a standards organization
ODBC
Open Database Connectivity a de-facto standard for remote
SQL
OMA
Open Mobility Alliance
OMG
Object Management Group the group that developed CORBA
OODBMS Object-Oriented Database Management System
OOPL
Object-Oriented Programming Language
OS
Operating System
OSF
Open Software Foundation
OSF-DCE OSF Distributed Computing Environment
OSF-DME OSF Distributed Management Environment
OSI
Open System Interconnection
PBX
Private Branch Exchange
PGP
Pretty Good Privacy
PKI
Public Key Infrastructure
QoS
Quality of Service
QPSK
Quadrature Phase Shift Keying
RDA
Remote Database Access
RFID
Radio Frequency Identification
RPC
Remote Procedure Call
SCM
SET
SNMP
SOAP
SONET
SQL
SSL
TCP
TCP/IP
UDDI
UDP
UMTS
UWB
VAN
VPN
VXML
WAN
WAP
WLL
WML
WS
WSN
Supply Chain Management
Secure Electronic Transaction a security standard
Simple Network Management Protocol - TCP/IP Network
management Protocol
Simple Object Access Protocol part of Web Services
Synchronous Optical Network
Structured Query Language
Secure Socket Layer
Transmission Control Protocol
Transmission Control Protocol/Internet Protocol
Universal Description, Discovery and Integration - a registry for
Web Services
User Datagram Protocol - a protocol that runs on IP
Universal Mobile Telecommunication System (Mainly 3G
Cellular Technology)
Ultra Wideband
Value-added Network
Virtual Private Network
Voice eXtensible Markup Language
Wide Area Network
Wireless Application Protocol
Wireless Local Loop
Wireless Markup Language
Web Services
Wireless Sensor Network
0. Overview of Service Disaster Management Service
(Basic)*
Overview
The basic disaster management (DM) service is intended for small cities, villages, communities and islands with
populations less than 100,000. It will support the small enterprises through the Learn-Plan-Do-Check cycle of
Disaster Management.
Disasters, natural or man-made, are frequent occurrences with impact that can greatly range in scope. The
following basic parameters can be used to define a disaster:


Type of disaster such as fire, flood, explosions, earthquakes, etc.
Geographic location of the incident (such as a building, city, island, region, or a country)

Type of DM needed. i.e., general population (neighborhood, villages etc.) or business continuity planning
and recovery services.
Advances in ICTs can minimize and even mitigate the impact of disasters and expedite recovery efforts. Howeve
these technologies and the wide range of services need to be architected and integrated for a smooth operation. A
Disaster Management Portal, displayed below, can provide such an integration point and the backbone for all of
services needed for DM. The conceptual view presented shows the following key components of DM Portal:





A Dispatch Subsystem that serves as the central nerve center of the DM portal and provides view
integration of all the services and access controls for different users.
Communication capabilities through wired and wireless networks with intelligent sensors that are needed
inform the public, the officials and the various participants.
Essential services such as hospital, police, fire and other departments such as towing to trigger and mana
the recovery services.
Guidance services such as environmental (weather) data, traffic information, and geospatial information
services (GIS).
Decision support services that include query and data analytics, business Intelligence, and a data warehou
1. Overview and Business Drivers
Web Publishing
Publishing content on the web is one of the oldest application of web. You basically store your
files (HTML/XML) on a web server so that the customers can access this content through Web
browsers. The growing number of Web sites that publish content (known as "resources") to be
accessed transparently by Web users is the main strength of WWW. Examples of the Web sites
at present are corporate Web sites, university Web sites, publishing/advertising Web sites, travel
agency Web sites, and small business Web sites. Web sites can be large (e.g., large corporations
may dedicate several machines as Web sites) or small (smaller companies may rent or lease
portions of a Web site).
Business Needs (edit and modify to fit your needs)
















need to improve sales
need to improve customer satisfaction
need to provide new services
need to re-engineer business processes for efficiency
need to standardize operational processes.
need to gain economy in services, support, and buying power.
need for better reporting. And tracking
need to enable integration / automation with internal systems .
need to enable integration / automation with external providers (B2B) .
need to improve workflow mechanism to capture and manage business processes.
need to eliminate individually programmed software that provides little or no
compatibility between markets, regions, and headquarters.
need for a support system that provides auditing, tracking, interfacing, and automation of
tasks and workflows.
need to reduce duplicity in data, processes, and effort.
need to improve forecasting and budget tracking in all facets of the business.
need to quickly design and implement processes and technology changes across the
organization.
need to monitor depreciation of assets.
2. Background Information
Web Publishing
Additional Information
Although conceptually a Web site is a catalog of information for each content provider over the
Web, in reality, a Web site consists of three types of components: :


Content files such as the HTML documents
A Web server (a program) that receives browser calls and accesses contents, and/or

Gateways that can generate Web content (e.g., generate HTML pages) and provide access
to non-Web content (e.g., relational databases).
Setting up a Web site involves a large number of issues such as the following:







Deciding who will develop the Web site, i.e., your own organization or an outside service
provider.
Determining rent versus own issue, i.e., will the site be owned by your organization or
will you rent/lease space on an existing Web site (this is called "virtual hosting").
Choosing a Web site platform, i.e., will the Web server and contents reside on a UNIX or
Windows NT platform.
Choosing a sharing level, i.e., will a machine be dedicated as a Web site or the Web site
software will coexist with other software (e.g., LAN software).
Providing and controlling access to the site, i.e, determine the networking configurations
and the security firewalls to be set up.
Designing the site, i.e., designing home pages, assigning defaults, and server
configurations.
Management and support considerations such as backup/recovery, site security, site
administration, hotline support, etc.
Many Web servers for different classes of Web users are state of the market. Apache, Sun
Server, and Netscape servers are examples. The choice of a server depends on factors such as
ease of installation, performance, security, manageability, and user friendliness.
Web publishing represents the C2B - information services business pattern.
Web Site Usability Characteristics
Good
Fun to use
Aesthetic graphics
Good task flow
Relevant and Updated
Content
Smart Filtering/Sorting
Smart Compare Products
Feature
Good Information
Architecture
Error Prevention
Simplicity
Clarity
User-Centric
Consistent
Bad
Bad
Navigation/Poor
Menus
No visible
Search Bar
Misleading
Information
Crowded Space
Intrusive Ads
Too much
scrolling
Poor
Information
Architecture
Overly driven
by
marketing/Public
Relations
Poor Task Flow
Poor
Affordances
Bad Domain
Name
Unreadable
Text/Poor
Graphics
Distracting
content
Non-Relevant
or old Content
Business Pattern
In this pattern, the enterprises
are mainly information
providers. No purchasing takes
place (that is a different
business pattern).
This is one of the oldest model
of Web and is largely used for
advertisements and
information dissemination
through Web sites. Users, who
can be either internal or
external to the enterprise,
interact with enterprise
transactions and data. In some cases, there may be a need to access back-end applications and
data. This pattern is relevant to those enterprises dealing with goods and services not normally
listed in and sold from a catalog. It encompasses all user-to-business interactions not covered by
the User-to-Online Purchase pattern. Many (but not all) of the functions supported by the User to
Business pattern relate to Customer Relationship Management (CRM) systems.
Examples:
Government




Submit tax returns
Renew automobile licenses
Download forms/applications
Submit forms/applications
Manufacturing



Review required parts/services
Locate service centers
Register for training classes
Submit/track orders
Insurance Industry







Locate a nearby office
Locate brokers or agents
Financial planner and insurance needs analysis tool
Portfolio summary
Policy summary and details
Claims submission and tracking
Online billing
Discount Brokerage





Portfolio summary
Detailed holdings
Buy and sell stocks
Transaction history
Quotes and news
Convenience Banking





View account balances
View recent transactions
Pay bills/transfer funds
Stop payments
Manage bank card
3. Application Functional Requirements
Additional Information
Functional Requirements
A DM portal must support the following key subsystems that satisfy the basic functional
requirements stated below:
A Dispatch Subsystem that

serves as the central nerve center of the DM portal that supports the users, the officials,
and the participants


provides view integration of all the services from diverse sources such as hospitals,
police, fire, traffic controls, GIS and others
access controls for different type of users (e.g., citizens, emergency service providers,
etc)
Communication capabilities through



wired networks for fast broadband services
wireless networks for access from mobile devices
intelligent sensors that can detect the possible disasters early to inform the public, the
officials and the various participants for early responses.
Essential services such as




Hospital information systems that display the type of services available at different
hospitals, including emergency medical services
Police information systems to help coordinate the rescue processes
fire department systems to carry out the rescues
towing to trigger and manage the recovery services
Guidance services such as



environmental (weather) data to keep the public informed of tornados, snow and other
fluctuating weather conditions
traffic information to show what paths should be taken in an emergency
geospatial information services (GIS) to help locate the needed hospitals, rescue centers
and disaster sites
Decision support services that include




A data warehouse (DW) with BIG Data capabilities that include data of different forms
and nature (e.g., historical data, statistical data, etc)
query capabilities for simple adhoc queries against the DW
data analytics capabilities to provide descriptive, predictive and prescriptive analysis of
the data contained in the DW
business Intelligence capabilities to mine the DW for patterns and future actions
Web publishing Main Functional Requirements





Support static content in HTML and XML documents
Support dynamic content through gateways that can dynamically generate Web content
from non-Web resources (e.g., relational databases).
Intuitive and natural design.
Support a Web standard Web server (MS IIS or Apache)
Support Linux or Windows platform.


Provide appropriate sharing level (dedicated versus shared machine)
Support backup/recovery, site security, site administration, hotline, etc.
4. Information Models (Use Cases, Class Diagrams,
Sequence Diagrams)
== Insert information models here
5. Logical Architecture (Application Pattern)
Disaster Management Service (Basic)*Logical Application Architecture
This logical architecture consists of the following (see the diagram)





Business Layer that
provides the business
services such as the
following:
Backend resources
External
(Partner/Supplier)
Resources
o These may be
government
and/or
regulatory
agencies.
The Front-end Integration Layer that allows different types of user devices (e.g.,
handhelds, voice over IP) to invoke the Business Layer. This layer:
o Integrates the diverse user device technologies
o Provides necessary security services
Back-end Integration Layer that interacts with different back-end and external
applications. This layer:
o Integrates the diverse back-end databases and applications
o Provides necessary security services
6. Architecture and Integration Requirements (General)
Distributed Architecture Requirements
== Modify the following as needed

The application must be decomposed into well defined business components that can be
deployed, installed, and invoked independently over the Internet.






The application must support an N tiered (N > 2) architecture with client, server, and
databases.
The architecture must support a front-end as well as back-end integration tiers.
The application must support a replication mechanism so that all data and processes do
not reside on one location.
All levels of the architecture must be both forward and backward compatible.
The application must be highly configurable within the server environment allowing for
multiple workflow options concurrently.
The application must allow for internal application customization in a GUI environment.
Interface/Integration Requirements
== Modify the following as needed










The application must support well defined interfaces for external integration.
The application programming interface must be documented and supported.
The application must provide loose coupling with external systems for flexibility
The application must have a browser-based GUI for user interactions
The application must have conversion capabilities for different financial and regional
data items (e.g., dollars to Euro).
The application must be able to download external data files .
The application must be able to process transactions with third party systems.
The application must be able to interchange status information with third party systems
for logistics functions.
The application should be capable of supporting data mining applications.
The application must provide an effective and efficient interface for highly mobile
personnel.
7. Architecture and Integration Requirements
Front-end Considerations

Simple Web browser interface over HTTP because of lightweight informational
interaction
Back-end Considerations


No interfaces with back-end systems
No data translation needed for back-end applications
B2B Considerations


No interfaces with external systems for B2B interactions
No data translation needed for B2B applications
Special Considerations

Scalability of this service should be a (major) concern due to the population of intended
users.
8. Operational Requirements (Generic)
Security/Permission Requirements





The solution shall allow for the creation of privileges and permissions based on work
groups composed of different users at different sites.
The solution shall enforce privileges and permissions on data fields and user screens.
The application will support privileges for read, delete, and edit.
A local administrator will be able to assign all user privileges and permissions.
The application must conform to security standards, policies, and procedures established
by the company
Performance Requirements




The system must provide adequate turnaround for interactive work.
The system should be robust to handle user access needs without crashes and restarts
The system must allow backup of needed data while being continually available to users
for business as usual operations.
The system should degrade performance gracefully if workload increases dramatically.
Hardware Requirements





The application server must support the following platforms: Windows/Linux/Others
(specify)
The application server must support the following platforms: Windows/Linux/Others
(specify)
The application client must support the following platforms: Windows/Linux/Others
(specify)
The application must support a hardware High Availability environment through
replicated servers.
Add more
Software Requirements





The application server must utilize the most recent operating systems from the following
list: Windows/Linux/Others (specify)
The application client must utilize the most recent browser version from the following
list: Internet Explorer/Netscape/FireFox (specify)
The application must utilize relational databases.
The application must utilize a commonly available and used development environment
such as Rational Rose.
Add more
9. Vendor Support Requirements
Application Service Provider (ASP) Support





The ASP must guarantee, in writing, complete privacy and security of application and
data.
The ASP must support the application 24 hours a day, 7 days a week, 365 days a year.
Response of an application failure must be made according to the failure types by the
ASP. The application shall use 3 failure types: critical, important, and minor.
o Critical failure shall mean that the System is un-useable. The response to a critical
shall be immediate to 3 minutes with 30 minutes to repair after vendor
notification.
o An Important failure shall mean that some part of the system is un-useable. The
response to an important failure shall be 1 hr with 4 hrs to repair after vendor
notification.
o A Minor failure shall mean that impairment is affecting application performance.
The response to a minor failure shall be within 24 hours with 7 days to repair after
vendor notification.
The ASP will support necessary upgrades of the software features.
The ASP must provide all the necessary documentation needed for the customer to use
the applications (e.g., a user guide, troubleshooting information, etc).
Back Up and Maintenance Support



The backup files shall be generated and stored according to the following IT standards
o backups will be taken once a day (recommended) or once a week (required)
o backup copies will be stored at an external site for safety
The application shall support an incremental online backup of the complete system,
including database, as well as a full weekly online backup..
The application vendor must provide maintenance and upgrades on a regular basis.
Documentation Support
The application provider, in the following discussion, may be an outsourced development house
or an internal software development group.
o
o
o
o
o
o
o
The application vendor must provide a Users guide for all user categories interfaces.
The application vendor must provide an Administrators guide for the application.
The application vendor must provide online Help on all client interfaces.
The application vendor must supply documentation on the applications maintenance.
The application vendor must provide documentation on each database used in the
proposed solution.
The application vendor must supply upgrade instructions and release notes 30 days
before a release.
The application vendor must provide upgrade and rollback procedures for new releases.
Training Support
o
o
The application vendor must provide on-site and/or application vendors site training. .
The application vendor must provide interactive training on CD-ROM or through Web.
10. SOA Considerations









Eliminate redundancy among services.
Services should be reused instead of created whenever possible
Services must be compliant with the existing reference architecture
Services should have a different response time based on the access method
Give priority to services with highest value and highest potential for reuse.
Decide which services to do? And, which services to do first?
Determine how will SOA development, execution, and maintenance of shared
services be funded
Determine who owns the service
Ensure that SOA projects remain aligned with business goals and deliver the
expected business results
Main Suggestion:

Create a process for proposing services, for example:
o Proposals are submitted to a team room
o Require documentation/justification
o Reviewed weekly by a committee established by the SOA Center of
Excellence to respond:
 Accepted.
 Already exists, use that one
 A similar service is planned by another group. Coordinate with
them.
 Inappropriate (low value, low potential for reuse)
 Use external / outsourced service
Suggestion
For Interoperability: A common approach used in interoperability is an ontology mapping table
(OMT). Simply stated, ontology represents a vocabulary. An OMT translates the terms in one
system to the other and thus provides the bridge between disparate systems (see a simple
example below).
Term in
System1
Customer
Term in
System2
Buyer
Laptop
Item
Computer
Product
Many organizations are pushing the use of the Semantic Web (with XML) for interoperability
with focus on eGovernment, eHealth or eBusiness. Examples are:






eGovernment-based interoperability initiative in UK, called e-GIF
The European Commission provides a framework IDABC (Interoperable Delivery of
European eGovernment Services to public Administrations, Businesses and Citizens)
Large EU projects related to cross-border systems are http://www.eu-spocs.eu/ and
http://ec.europa.eu/information_society/apps/projects/factsheet/index.cfm?project_ref=22
4993There is a Semantic Interoperability Centre Europe (SEMIC.EU).
A European Land Information Service (EULIS) is a consortium of European National
Land Registers.
In the United States, the government's www.CORE.gov service provides a collaboration
environment for component development, sharing, registration, and reuse.
In the US, eGovernment Enterprise Architecture Guidance (www.cio.gov/documents/EGov_Guidance_July_25_Final_Draft_2_0a.pdf) and the E-Gov Enterprise Architecture
Guidance (Common Reference Model provide detailed interoperability specifications.