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...... 7
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...... 8
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...... 9
3.1.1 Make Invitation...... 11
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...... 12
3.1.3 Transaction...... 13
3.1.4 Update Invitation...... 14
3.1.5 RSVP...... 15
3.1.6 Manage RSVP...... 16
3.1.7 Monitor Site...... 17
3.2 External Interface Requirements...... 18
3.2.1 User interfaces
3.2.2 Hardware interfaces
3.2.3 Software interfaces
3.2.4 Communication interfaces
3.3 Performance Requirements...... 18
3.4 Design Constraints...... 18
3.4.1 Standards compliance
3.4.2 Hardware limitations
3.4.3 Software limitations
3.4.4 Environmental
3.5 Attributes...... 19
3.5.1 Availability
3.5.2 Security
3.5.3 Maintainability
3.5.4 Transferability/conversion
3.6 Other Requirements...... 19
3.6.1 Database
3.6.2 Operations
3.6.3 Site adaptation
List Of Figures
Analysis Use Case Diagram...... 9
Analysis Class Diagram...... 10
Sequence Diagrams
Make Invitation...... 11
Distribute Invitation...... 12
Transaction...... 13
Update Invitation...... 14
RSVP...... 15
Manage RSVP...... 16
Monitor Site...... 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
DBMSDataBase Management System
EISEngraved In Stone
HTMLHyperText Markup Language
HTTPHyperText Transfer Protocol
IEEEInstitute of Electrical and Electronics Engineers
MIMEMultipurpose Internet Mail Extensions
MISManagement Information Systems
RSVPRepondez Sil Vous Plait
SRSSoftware Requirements Specification
SSLSecure Socket Layer
TBDTo Be Determined
TBRTo Be Resolved
UMLUnified 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.
3.1.1 Make Invitation
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
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
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
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
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
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
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.