Download 1 - brains-N

Engraved In Stone
Researching MIS: Electronic Commerce Business Startup
Software Requirements Specification
Release 2.0
7/20/99
Casey Chesnut
Aaron Wardrum
THIS PAGE INTENTIONALLY LEFT BLANK
Table Of Contents
1. Introduction
............................................................
1.1 Purpose of SRS
1.2 Scope of product
1.3 Definitions, acronyms, and abbreviations
1.4 References
1.5 Overview of rest of SRS
2. General Description
............................................................
2.1 Product perspective
2.2 Product functions
2.3 User characteristics
2.4 General constraints
2.5 Assumptions and dependencies
3. Specific Requirements
3.1 Functional Requirements
............................................................
3.1.1 Make Invitation
............................................................
3.1.1.1 Introduction
3.1.1.2 Inputs
3.1.1.3 Processing
3.1.1.4 Outputs
3.1.2 Distribute Invitation
............................................................
3.1.3 Transaction
............................................................
3.1.4 Update Invitation
............................................................
3.1.5 RSVP
............................................................
3.1.6 Manage RSVP
............................................................
3.1.7 Monitor Site
............................................................
3.2 External Interface Requirements ............................................................
3.2.1 User interfaces
3.2.2 Hardware interfaces
3.2.3 Software interfaces
3.2.4 Communication interfaces
3.3 Performance Requirements
............................................................
3.4 Design Constraints
............................................................
3.4.1 Standards compliance
3.4.2 Hardware limitations
3.4.3 Software limitations
3.4.4 Environmental
3.5 Attributes
............................................................
3.5.1 Availability
3.5.2 Security
3.5.3 Maintainability
3.5.4 Transferability/conversion
3.6 Other Requirements
............................................................
3.6.1 Database
3.6.2 Operations
3.6.3 Site adaptation
7
8
9
11
12
13
14
15
16
17
18
18
18
19
19
List Of Figures
Analysis Use Case Diagram
............................................................
9
Analysis Class Diagram
............................................................
10
Sequence Diagrams
Make Invitation
Distribute Invitation
Transaction
Update Invitation
RSVP
Manage RSVP
Monitor Site
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
11
12
13
14
15
16
17
1. Introduction
1.1 Purpose of SRS
This document is the Software Requirements Specification for the Engraved In Stone
online wedding invitation system. It details the analysis effort being performed by the developers
of Engraved In Stone. This analysis effort should reflect the intentions of Engraved In Stone’s
Business Plan, as well as provide the basis for prototyping efforts and design of the online
wedding invitation system. Finally, this document will also be referenced during implementation
and testing of the final system.
1.2 Scope of product
The system provides for online wedding invitations. The wedding invitation is a
dynamically generated HTML page hosted at EngravedInStone.com. It consists of the
information traditionally dealing with the wedding and its associated events (showers, rehearsal
dinner, parties). The invitees of the individual events will be notified by email, supplied by the
purchaser of the invitation. The invitee will be able to RSVP to the invitation(s) and will be
provided with other communication services. The purchaser will be provided with an online
interface to manage the acceptance and rejection of invitations and other information services.
1.3 Definitions, acronyms, and abbreviations
DBMS
EIS
HTML
HTTP
IEEE
MIME
MIS
RSVP
SRS
SSL
TBD
TBR
UML
DataBase Management System
Engraved In Stone
HyperText Markup Language
HyperText Transfer Protocol
Institute of Electrical and Electronics Engineers
Multipurpose Internet Mail Extensions
Management Information Systems
Repondez Sil Vous Plait
Software Requirements Specification
Secure Socket Layer
To Be Determined
To Be Resolved
Unified Modeling Language
1.4 References
This document conforms to the IEEE 830 Standard for Software Requirements
Specifications. The UML artifacts are compliant with UML Version 1.1.
1.5 Overview of rest of SRS
The remainder of this document is organized as follows: Section 2 presents a General
Description of the system. Specific requirements are presented in Section 3. The specific
requirements are categorized as functional, external interface, performance, design constraints,
attributes, or other requirements. The functional requirements section includes the UML
analysis diagrams. The UML analysis artifacts are a use case diagram, sequence diagrams,
and a class diagram.
2. General Description
2.1 Product perspective
The proposed system allows users to invite friends and family to weddings through the
creation of web pages and email messages and allows those invitees to RSVP to related
events.
2.2 Product functions



Design Invitation – User selects from various formats the look and feel of their virtual wedding
invitation and specifies who are invited to the associated events.
RSVP Interface – Invitees accept or decline to the events they were invited to.
Reservation Management Interface – Inviters query system to check who has RSVP to the
various events and to update information regarding the invitation.
2.3 User characteristics
The users of this system are assumed to have a basic understanding of the Internet and
are in the process of planning a wedding.
2.4 General constraints
The system will be implemented using Java and HTML. The ISP hosting the system is
required to support Java Servlets.
2.5 Assumptions and dependencies
Tailored out of this document.
3. Specific Requirements
3.1 Functional Requirements
The functional requirements were derived from the following use case diagram. Use case
diagrams represent the functional interactions of a system. The stick figures represent the
actors, which are external to the system and interact with the system through interfaces. The
actors of the online wedding invitation system are the Inviter and the Invitee. The Inviter will
invite a number of Invitees to his wedding. The ovals are individual use cases that represent the
functions the system performs to provide the services that the actors desire. The use cases of
the online wedding invitation are: Make Invitation, Distribute Invitation, Transaction, Update
Invitation, RSVP, and Manage RSVP. The Transaction use case is unique in that it is not acted
on directly by an external actor. It represents a function that can only be performed indirectly
through the use of the Distribute Invitation use case. This is represented by the <<uses>>
relationship between Distribute Invitation and the Transaction use cases. The Inviter actor
interacts with the following use cases: Make Invitation, Distribute Invitation (Transaction),
Update Invitation, and Manage RSVP. The Invitee actor interacts with the following use cases:
Distribute Invitation and RSVP. The Invitee does not initiate the Distribute Invitation use case,
but is a data sink for the output of the Distribute Invitation use case, initiated by the Inviter.
The online invitation system was also modeled as a class diagram. Class diagrams
represent the static associations between objects in the system. The classes derived from the
analysis are: Inviter, Reservation, Invitation, and Mail. Inviter was an external actor in the use
case view, but it was determined that a class would also have to be developed to maintain state
for individual actor objects. Invitee remains as an actor in the system in the static view because
it was not deemed necessary at this point in time to collect their state information. The
information needed to contact Invitee’s is currently handled by the Mail class. The associations
between the classes, show which objects can interact directly and indirectly with other objects.
Attributes and methods were only defined in so much as to help describe the primary purpose of
the class. UML design artifacts, such as collaboration diagrams, would provide the exercise to
flesh out the complete set of attributes and methods necessary to support the system. The
system is decomposed in these low level objects to that Engraved In Stone can experience
reuse. An example might be that the Mail class could be reused in a baby announcement
system.
Finally, the dynamic aspects of the system are modeled as sequence diagrams. Each use
case has its own corresponding sequence diagram. The sequence diagram shows the flow of
data between the system and external actors through interfaces, as well as for the flow of data
and message calls between objects internal to the system. Data cannot flow between actors
and objects unless they have the appropriate association represented in the class diagram.
Only some of the objects of the class diagram are required to support the function of each
individual use case. The scenarios represented are the most common path through the system
and do not detail alternate scenarios. The scenarios are also time dependent and happen in
sequence. The transitions internal and external to scenarios might be either synchronous or
asynchronous.
: Invitation
3.1.1 Make Invitation
: Inviter
initiate order
display available packages
choose package
display invitation template
choose template
display contact information form
contact information
display wedding service info form
wedding service info
display associated event info form
info
guest and registry info form
info
ceremony details form
info
display information for confirmation
confirm
display image file upload form
image files
generates invitation
invitation preview
DISTRIBUTE INVITATION USE CASE
3.1.1.1 Introduction
The Inviter uses a web browser client to access the Engraved In Stone web server to
create the wedding invitation online.
3.1.1.2 Inputs
The Inviter inputs the appropriate textual and graphical data into the html forms,
concerning the wedding ceremony itself, and submits the information to the web server.
3.1.1.3 Processing
The web server manages the collection of the data from the html forms and uses the
information to generate the online wedding invitation.
3.1.1.4 Outputs
The online wedding invitation is presented to the Inviter, so that he/she may preview it.
3.1.2 Distribute Invitation
: Mail
: Inviter
: Invitee
initiate distribution
display guest list form
attendants
generate guest/event matrix
display guest/event matrix form
designate attendants for specific events
display personal message form
personal message text
TRANSACTION USE CASE
generate email message
sends email messages
3.1.2.1 Introduction
The Inviter uses a web browser client to access the Engraved In Stone web server to
specify who should be notified of the online wedding invitation.
3.1.2.2 Inputs
The Inviter inputs the appropriate textual data into the html forms, concerning the Invitees,
and submits the information to the web server.
3.1.2.3 Processing
The web server manages the collection of the data from the html forms and uses the
information to dynamically generate email messages. The Transaction use case occurs
within the context of this sequence.
3.1.2.4 Outputs
The email messages are sent to the appropriate Invitees to notify them of their online
wedding invitation.
3.1.3 Transaction
Actor : Inviter
: Owner
: Inviter
initiate financial transaction
display transaction form
credit card info
process transaction
transaction tracking info
payment
provide notice of invitation creation
DISTRIBUTE INVITATION USE CASE
3.1.3.1 Introduction
The Inviter uses a web browser client to access the Engraved In Stone web server to offer
the monetary transaction information to purchase the online wedding invitation. This entire
sequence is performed over a secure connection.
3.1.3.2 Inputs
The Inviter inputs the appropriate textual data into the html form, concerning the monetary
transaction, and submits the information to the web server.
3.1.3.3 Processing
The web server accepts the information and passes it an external system which solely
provides the means to process online transactions.
3.1.3.4 Outputs
A dynamic html page is generated and displayed to the Inviter, so that the Inviter can
monitor and track the state of the transaction.
3.1.4 Update Invitation
: Invitation
Actor : Inviter
initiate update
display information form with current info
modified information
regenerate invitation
update confirmation
3.1.4.1 Introduction
The Inviter uses a web browser client to access the Engraved In Stone web server to
update and modify the information presented on the online wedding invitation.
3.1.4.2 Inputs
The Inviter inputs the appropriate textual data into the html form, concerning the
previously generated invitation, and submits the updated information to the web server.
3.1.4.3 Processing
The web server manages the collection of the data from the html forms and uses the
updated information to regenerate the online wedding invitation.
3.1.4.4 Outputs
The Inviter is presented with an html page confirming the invitation has been successfully
updated.
3.1.5 RSVP
: Reservation
: Invitation
: Mail
: Invitee
receives email message
views invitation
RSVPs
update reservation list
RSVP confirmation
3.1.5.1 Introduction
The Invitee receives notification of the online wedding invitation through email and uses a
web browser client to access the Engraved In Stone web server to RSVP for the event.
3.1.5.2 Inputs
The Invitee inputs textual information into the html form aspect of the online wedding
invitation and submits the information to the web server.
3.1.5.3 Processing
The web server manages the collection of the data from the html form and uses the
information to update the reservation list hosted on the server.
3.1.5.4 Outputs
The Invitee is presented with an html page confirming the reservation has been
successful.
3.1.6 Manage RSVP
: Reservation
: Inviter
initiate reservation review
generate RSVP page
display reservations
updates reservations
update reservation list
update confirmation
3.1.6.1 Introduction
The Inviter uses a web browser client to access the Engraved In Stone web server to view
and update the reservation list for the associated online wedding invitation.
3.1.6.2 Inputs
The Inviter inputs the appropriate textual data into the html form, concerning the
reservation list, and submits the additional information to the web server.
3.1.6.3 Processing
The web server manages the collection of the data from the html forms and uses the
additional information to update the reservation list.
3.1.6.4 Outputs
The Inviter is presented with an html page confirming the reservation list has been
successfully updated.
3.1.6 Monitor Site
: Invitation
: Owner
: Inviter
request list changed/modified invitations
display most recent invitations
select invitation to audit
display selected invitation and associated information
audit invitation and transaction for errors
notify inviter of any errors
fix error
3.1.7.1 Introduction
The Owner uses a web browser client to access the Engraved In Stone web server to
monitor the online wedding invitations and email messages that have been produced.
3.1.7.2 Inputs
The Owner selects the online wedding invitation to monitor from a list of the most recently
created/modified invitations.
3.1.7.3 Processing
The web server updates the list of most recently created wedding invitations the links to
its associated data store information stored as files.
3.1.7.4 Outputs
The Owner views the chosen online wedding invitation to monitor that the online wedding
invitation system is working correctly.
3.2 External Interface Requirements
3.2.1 User interfaces
All user interfaces (Inviter, Invitee, Owner) are web-based HTML pages which can be
accessed through any standard web browser. Web pages which ask for user input will include
HTML forms. These HTML forms need to include JavaScript code to verify that the
appropriate information has been input before allowing the information to be submitted to the
web server. Web pages which provide confirmation information will be dynamically generated
static HTML pages.
3.2.2 Hardware interfaces
There are not direct hardware interfaces in the system. The operating systems on both
the client and server side will be configured to handle the hardware interfaces.
3.2.3 Software interfaces
The client side software interface will be through any standard web browser. The server
side interface will be through a Java web server.
3.2.4 Communication interfaces
Communication between the client and servers will occur between the standard internet
protocol HTTP. Mail transfers and file uploads will be accomplished through MIME.
3.3 Performance Requirements
There are currently no performance requirements because the system is not data,
processing, or bandwidth intensive. Security and reliability are more important. If performance
becomes an issue in the future, the web server can be upgraded, or the system can be
integrated into an application server environment connected to a backend DBMS.
3.4 Design Constraints
3.4.1 Standards compliance
The system complies with the internet standards of HTML, HTTP, and MIME. These
standards support the largest number of online customers.
3.4.2 Hardware limitations
There are no hardware limitations to be considered.
3.4.3 Software limitations
At this point in time it is not viable for Engraved In Stone to purchase professional web
hosting services. Because of this, files must be used for persistence of data to be used by the
web server, instead of persisting the data to a DBMS. Another limitation is the use of a Java
web server instead of an application server. Because of this, the system will have to
incorporate its own online transaction processing services as well as handle concurrent
access by multiple clients.
3.4.4 Environmental
The client side will run on any environment which supports a web browser. The server
side environment will not be a concern to the clients, and can be upgraded/changed as
necessary, without effecting the clients.
3.5 Attributes
3.5.1 Availability
The system has to be available at all times.
3.5.2 Security
The system has to provide secure internet connections (SSL) for the transfer of private
data. The web hosting service should provide security services so that third parties cannot
modify the information hosted on the web site. Users will have to login to the system. Logging
in will determine what level of access the user has with the system and the views with which
they are provided.
3.5.3 Maintainability
The system has to provide Invitees with the ability to maintain their own invitation. Owners
will maintain the set of invitations that are being hosted at any one time. The web hosting
administrators will maintain the server that is hosting the system.
3.5.4 Transferability/conversion
There are no transferability concerns for the client side. The server side should be
designed in such a manner so that the system can be transferred to a different web hosting
service without effecting day to day operations.
3.6 Other Requirements
3.6.1 Database
A database is not required from the offset. Files will be used to handle data storage.
3.6.2 Operations
Backups will be performed by both the owners and the administrators of the web hosting
service.
3.6.3 Site adaptation
The site will be adaptable to the different users of the system, according to the access
associated with the login that they provide.