AGW654 Service System

Process & Development

A sophisticated dynamic
Website
Case: Vista Hotel

System Document
(SPMP, SRS, SDD, STD, STR)

For:

Vistana Hotel

By:

Mohammad Iranmanesh (P_GSM_0197/09)

Wan Sharinee Fitra Wan Yahaya(P-GSM0178/09)

GSB
Universiti Sains Malaysia
11800 USM
Penang, Malaysia
Session 2009/2010

PSH-SYSDOC-2.1
AGW654 Final Year Project [A sophisticated dynamic Website]

Document Revision History

Revision Date Updated by Description

PSH-SYSDOC-2.1 ii
AGW654 Final Year Project [A sophisticated dynamic Website]

Table of Contents

1. Software Project Management Plan (SPMP).......................................................................8

1.1. System Overview.........................................................................................................8

1.1.1. System Description and Function.......................................................................8

1.1.2. Development Methodology.................................................................................9

1.1.3. Software Lifecycle...............................................................................................9

1.1.4. Modeling Notation.............................................................................................13

1.1.5. Coding Standard...............................................................................................13

1.2. Team Structure and Roles.........................................................................................13

1.2.1. Role Assignments.............................................................................................14

1.2.2. Development Responsibilities...........................................................................14

1.3. Facilities and Computer Resources...........................................................................14

1.3.1. Workspace Requirements and Allocation.........................................................14

1.3.2. Computer and other Hardware Resources.......................................................14

1.3.3. Software and Operating System Resource Specifications...............................14

1.4. Risk Management......................................................................................................14

1.4.1. Areas of Risk.....................................................................................................15

1.4.2. Monitoring Procedure and Contingency Plan...................................................15

1.5. Reviews......................................................................................................................15

1.5.1. Formal Reviews................................................................................................15

1.5.2. Informal Reviews...............................................................................................15

1.5.3. Review Progress...............................................................................................16

1.6. Project Schedule & Milestones..................................................................................16

1.6.1. Phase I (Requirements)....................................................................................16

1.6.2. Phase II (Design & Development: Prototype Version 1)..................................17

1.6.3. Phase III (Development & Delivery: Versions 2 & 3)........................................17

2. Software Requirements Specifications (SRS)....................................................................19

PSH-SYSDOC-2.1 iii
AGW654 Final Year Project [A sophisticated dynamic Website]

2.1. Engineering Requirements........................................................................................19

2.2. Top Level Representation..........................................................................................19

2.3. External Interfaces Requirements.............................................................................19

2.3.1. Interface [Actor 1 / XYZ System]......................................................................20

2.3.2. Interface Order Clerk / CSS..............................................................................20

2.4. Internal Interfaces Requirements for [Subsystem/Module 1]....................................21

2.4.1. [Statechart Diagram 1]......................................................................................21

2.4.2. [Statechart Diagram 2]......................................................................................21

2.4.3. [Use-Case 1].....................................................................................................21

2.4.4. [Use-Case 2].....................................................................................................21

2.5. Internal Interfaces Requirements for Subsystem Order-Entry..................................22

2.5.1. Statechart Diagram for Order Item...................................................................23

2.5.2. Use-Case: Create New Order: Telephone Order.............................................23

2.5.3. [Use-Case 4].....................................................................................................24

2.6. Non-Functional Requirements...................................................................................25

2.6.1. Space Requirement..........................................................................................25

2.6.2. Performance Requirement................................................................................25

2.6.3. Other Relevant Non-Functional Requirement..................................................25

3. Software Design Description (SDD)...................................................................................26

3.1. Storyboard..................................................................................................................26

3.2. High Level Design......................................................................................................26

3.2.1. System Architecture..........................................................................................26

3.2.2. System Packages.............................................................................................27

3.3. Integration Interfaces.................................................................................................27

3.3.1. [Package 1] I/O Interfaces................................................................................27

3.3.2. [Package 2] I/O Interfaces................................................................................27

3.4. Detailed Design for [Package 1]................................................................................28

3.4.1. Detailed Sequence Diagram: Create New Order.............................................28

PSH-SYSDOC-2.1 iv
AGW654 Final Year Project [A sophisticated dynamic Website]

3.4.2. Class OrderItem................................................................................................28

3.4.3. State Transition Diagrams................................................................................29

3.4.4. Flowchart / Pseudocode...................................................................................29

3.5. Detailed Design for [Package 2]................................................................................29

3.5.1. Detailed Sequence Diagrams...........................................................................29

3.5.2. [Class Design 1]................................................................................................30

3.5.3. [Class Design 2]................................................................................................30

3.5.4. State Transition Diagrams................................................................................30

3.5.5. Flowchart / Pseudocode...................................................................................30

4. Software Test Documentation (STD)..................................................................................31

4.1. System Test Cases....................................................................................................31

4.1.1. [Test Case 1].....................................................................................................31

4.1.2. [Test Case 2].....................................................................................................31

4.2. Unit Test Cases for [Module 1]..................................................................................31

4.2.1. [Test Case 1].....................................................................................................32

4.2.2. [Test Case 2].....................................................................................................32

4.3. Test Cases for Subsystem Order-Entry.....................................................................32

4.3.1. Test Case: Create New Order [STD-0003].......................................................32

5. Software Test Report (STR)...............................................................................................33

5.1. System Test Reports.................................................................................................33

5.1.1. [Test Report 1]..................................................................................................33

5.1.2. [Test Report 2]..................................................................................................33

5.2. Unit Test Reports.......................................................................................................33

5.2.1. Create New Order.............................................................................................33

5.2.2. [Test Report 1]..................................................................................................34

6. REFERENCES...................................................................................................................36

PSH-SYSDOC-2.1 v
AGW654 Final Year Project [A sophisticated dynamic Website]

List of Figures

Figure 1.1: Complete System Module Breakdown........................................................................9

Figure 1.2: Rapid Prototyping Lifecycle with Software Versioning...............................................9

Figure 1.3: Phase I GANTT Chart...............................................................................................16

Figure 1.4: Phase II GANTT Chart..............................................................................................18

Figure 1.5: Phase III GANTT Chart.............................................................................................19

Figure 2.1: Overall Use Case Diagram for CSS (Example)........................................................20

Figure 2.2: Overall Domain Model Class Diagram for CSS (Example)......................................20

Figure 2.3: Use Case Diagram for Order-Entry Sub system.......................................................22

Figure 2.4: Domain Class Diagram for Order-Entry Sub system................................................22

Figure 2.5: Statechart Diagram for Order Item............................................................................23

Figure 2.6: Use Case Description for Create New Order: Telephone Order Scenario...............24

Figure 3.1: Network Diagram of CSS Architecture......................................................................26

Figure 3.2: Design Class Diagram for CSS.................................................................................26

Figure 3.3: Package Diagram......................................................................................................27

Figure 3.4: Inter-Package I/O Parameters for [Package 1].........................................................27

Figure 3.5: Detailed Sequence Diagram for Telephone Order Scenario....................................28

Figure 3.6: Class OrderItem........................................................................................................28

Figure 3.7: Statechart for OrderItem...........................................................................................29

PSH-SYSDOC-2.1 vi
AGW654 Final Year Project [A sophisticated dynamic Website]

List of Tables

Table 1: Developing……………………………………………………………………………………………...11

Table 1.1: Project Team Role Assignments................................................................................14

Table 1.2: Module Development Responsibilities.......................................................................14

Table 1.3: Areas of Risk..............................................................................................................14

Table 1.4: Monitoring Procedure and Contingency Plan for Risks.............................................14

Table 1.5: Review Progress........................................................................................................15

Table 1.6: Phase I Task Assignments.........................................................................................17

Table 1.7: Phase II Task Assignments........................................................................................17

Table 1.8: Phase III Task Assignments.......................................................................................18

Table 2.1: Use Case Description for Create New Order: Telephone Order Scenario................23

Table 2.2: System Sizing Limitations..........................................................................................25

Table 2.3: System Timing Targets...............................................................................................25

Table 2.4: System Performance Goals.......................................................................................25

PSH-SYSDOC-2.1 vii
AGW654 Final Year Project [A sophisticated dynamic Website]

1. Software Project Management Plan (SPMP)

1.1. System Overview
1.1.1. System Description and Function
The purpose of this project is to change vistana hotel’s website from static website to dynamic
website and add value .Through this dynamic, website Vistana reach its mission with
interactive website in friendly environment.
Vision of vistana about their site: customer-centricity, starting from the customer and
working backwards and do what they want.

Mission of vistana about their site: To build a website that is easy to understand, two
ways and will be automatic responsible.

Current weakness in Vistana hotel’s website:

 The site is static and limit to present its environment and facilities(so we put
accommodation to present room features and room types to customer and
amenities to present hotel’s facilities like swimming pool, coffee net and etc. and
media to show different part of hotel to new customer.
 The website seem boring and don’t have friendly environment to communicate with
client and just is one way site, so we put capture guest’s contact and experience
option for customer that engage them to share their experience with new customers
and let us improve ourselves.
 As all statistic site, it use html and updating site is need change in html code and
need web designer so we move to dynamic website that let manager to update site
information easy.
 If check its html code, can see the web doesn’t have keywords for search engine
 The color is boring and some part it’s not enough contrast between the text and the
background(at first glance the site is boring)
 The price of room is not appear in home-page(at least can appear the lowest price in
home page by using database)
 Don’t have any database. We will have database according dynamic website and we
have this ability to have promotion according the free rooms.
 The confirm of room is manual and take 1day time, that by database can do it
atomically in one second.

PSH-SYSDOC-2.1 8
 AGW654 Final Year Project [A sophisticated dynamic Website]

Vistana Hotel’s website

Accommodation Amenities Meetings & Reservation Capture Guest’s

Events Contact/Autoresponder

Dining/Nightlife Entertainment Media Experience/ Mobile Site

Testimonial

Figure 1.1: Complete System Module Breakdown

1.1.2. Development Methodology

1.1.3. Software Lifecycle

This project uses the Rapid Prototyping Lifecycle with Versioning (Spiral Model) for the
development planning and scheduling.
Client Requirements
Meeting Analysis

Validation
Specification of
Operating System
Requirements
Validation
Installation & Maintenance Validation System Design

Alternative
Working System
Solutions
Testing
Validation

Technical
Specifications

Figure 1.2: Rapid Prototyping Lifecycle with Software Versioning

PSH-SYSDOC-2.1 9
AGW654 Final Year Project [A sophisticated dynamic Website]

Client requirements:
This is a new project. We will use a process oriented methodology for creating this dynamic
website. The methodology will include:
1.1.1.1 Planning- This phase is where we will interview our client to get all the necessary
details in order to design and plan a website for them. The questions that we will be
asking our client are who is this website for, why our client want to develop this
website, when does he wants this website to be completed and how does he want
the design to be. (In this stage, hotel’s manager is our customer, and he reflect us the
hotel’s customers need and we design website according website vision, and prepare
interaction option that encourage customer to share their experience and needs with
us and we develop our website by working backward from customers needs)
1.1.1.2 Analysys- The purpose of this website is to capture new customers and also the
existing customers to the hotel. This website will facilitate customers to make
reservation and payment online and provide them with the latest updated information.
The maintainance of the website is needed and we will be updating this website for
our client on contractual basis. We will be proposing to the client that we will maintain
the website and add values to the website in terms of technology enhancement for 5
years. As far as the technology, this website is already design with state of the art
technology meaning the latest. Since will be maintaining their website for 5 years,
we’ll be updating their website as new technology emerges.

Customer classification:
We have difference kind of customers with different requirement, so we need know
them and their requirement to can reach Vistana's website vision. We have 5kinds of
customers:

Loyal customers: They have experience with vistana hotel and choose vistana when
they travel to Penang or Kuala lumpur or Kuantan. They want to see the influence of
their recommendation and we need to be comminuting with this customer via email
and recommendation part.
Discount customers: They make their decisions, based on rate of rooms, so with
promotion and package we can promote them.

Impulse customer: They buy things that seems good at the time, so we need to
present them. Vistana's site need excite them by making the good sense in them about
hotel and service with interesting website and logical picture(logical picture like, put
one photo of dining room with alot of happy people inside)

Need-based customer:People in this category are driven by a specific need, when

they enter the website, they will look to see if they can have that need filled quickly.
If not, they will leave right away, so we need to present most important data
like(booking, rate, facilities,..)in home page and positive personal interaction is
required that can we do with sending personal email them later after immediate
response automically.
Wandering Customers: They have no specific need or desire in mind when they
come into the website. Rather, they want a sense of experience and/or community.They are
merely looking for interaction, they are also very likely to communicate to others the
experience they had with Vistana hotel, that they can reach to these information via our
comment part.

PSH-SYSDOC-2.1 10
AGW654 Final Year Project
3 SPECIFIC REQUIREMENTS
It should cover essential information for guest
It should be easy to understand with maximized the speed
It should be captive and interactive
Current weakness
Static website
Boring website
Don’t have keyword
Can’t pay online
Don’t have link to other website
Don’t present the feature of
hotel in homepage
Don’t have any group in famous
social website like facebook
Table 1-Developing
PSH-SYSDOC-2.1
[A sophisticated dynamic Website]
Developing
Make data warehouse
Possibility of client
feedback
Automat responsibility
Use better color and
design attractive website
Live music
Expand html code and
make keyword
Possibility of paying at the
booking time
Link to tourist website
Use flash(with logical pictures)
and add essential data to
homepage
Make a group in facebook and
invite our customer to become
our fan via our website
11
Value added
Promotion (discount
customers)
Product bundle(Exp: free
breakfast for one night
stay)
Real time direct
communication
Invest on royal
customers and Need-
based customers
Confirm of room
atomically
Client surf more time in
site
Make good sense about
hotel
Find new customer via
search engine
Give customer more confidential
Find new customer and make
more traffic on web
Find more Need-based
customers
Find fans from customers and
build more brand awareness
AGW654 Final Year Project [A sophisticated dynamic Website]

1.1.1.3 Design-Our design will look like this prototype :

http://wansharinee.com/HeartFeltHotel/

For Mobile site :

1.1.1.4 We decided to design the system using a content management system which after
doing a few studies on few CMS( Content management System) engines such as
JOOMLA, DRUPAL, WORDPRESS and XOOPS. Finally we decided on using
WORDPRESS since we are familiar with it and because it is known to have quite a
handful of SEO friendly plugins. Moreover GOOGLE seems to favor WORDPRESS
against other CMS engines and 60% information are search from GOOGLE.
1.1.1.5 Promotion-We recommended our client to use hybrid marketing which is, the
combination of online and offline promotions. Apart of designing and creating website
for the client, we will also add values to the service by helping the client built the

PSH-SYSDOC-2.1 12
AGW654 Final Year Project [A sophisticated dynamic Website]

client’s presence on the internet. In doing this, we have to optimize the website not
just with the hotel’s name but also with few keywords such as “hotel in Penang”,
“Penang’s Hotels”, “best hotel in Penang”, etc. These keywords are important
because not all end user will directly go to the hotel website. Most of the end users
will use search engines to find hotel in Penang, when they do this, hopefully the end
users will find our client website on the first few pages of the SERP (Search Engine
Page Result). Besides doing the SEO optimization, we will also be doing other types
of Online Marketing to make sure our client’s website get the traffic from the internet.
Thus, our client will not only rely on search engine traffic, but also will be getting end
users from other form of marketing. Below are some of the services that we intend to
employ :

1) article marketing - write articles about our client’s hotel and the activities that its
has and promote the articles to directories such as ezinearticles.com, goarticles.com
2) forum marketing
3) marketing thru social nworking sites such as fb, myspace,
4) promote to social bookmarking sites such as digg.com, propeller.com.
stumbleupon.com
5) videomarketing- utube,metacafe
6) marketing thru groups- google, msn, yahoo
7)image storing side- flickr.com
8)mktg thru PPC(pay per click) ads- google adsense. facebook ad.(With database we
can have promotion according our free rooms and reply customer after booking
atomically)

The purpose of doing all the above techniques are to get traffics to the website and to
get backlinks to our client’s website (Most Search Engines give page ranking according
to backlinks ( relevancy, authority, quantity ). The techniques listed above is not
comprehensive. We will keep using new promotional method as new technology
emerges.

1.1.1.6 Innovation- We are responsible for the continuous improvement of the quality for our
client site. Exp: user testing and evaluating where we will keep monitor and improving
the site base on the latest technology and their requirement.(make discussion part
and let our client share dare experience in hotel in this part and help new client have
better view of our hotel and help us to improve our weakness)

1.1.4. Modeling Notation

Describe the modeling notation used in this project, e.g., UML, E-R Diagrams, etc. This is
usually tied to the development methodology chosen in Section 1.1.2

1.1.5. Coding Standard

Vistana hotel already use html and had statistic website but we are going to use PHP and
mysql to design dynamic website. We use the platform in wordpress and design initial website,
and then improve the site by edit the html and PHP code, and use PHP to improve the safety of
site.

1.2. Team Structure and Roles

[This is a Phase I task and should be refined in Phase II & III as needed. Describe the
organizational structure of the project: the relation of this project to the overall project (if part of

PSH-SYSDOC-2.1 13
AGW654 Final Year Project [A sophisticated dynamic Website]

a larger system), and the relationship among the different projects; as well as the actual project
team and roles of respective team members]

1.2.1. Role Assignments

Each team member is a Developer. In addition, the following roles are assigned to the
respective team members.
Table 1.1: Project Team Role Assignments
Role Team Member
Project Leader
Quality Assurance

1.2.2. Development Responsibilities

The following team members have been assigned to the given Modules for the project.
Table 1.2: Module Development Responsibilities
Module Team Member
[Module 1] [Member 1]
[Module 2] [Member 2]

1.3. Facilities and Computer Resources

1.3.1. Workspace Requirements and Allocation
No need of extra working space. Just allocation for buying domain name and hosting.We will
use hosting provider hostgator.com

1.3.2. Computer and other Hardware Resources

Nil

1.3.3. Software and Operating System Resource Specifications

We are using WORDPRESS engine, and mysql, and develop website with edit html and PHP
code.

1.4. Risk Management

[This is a Phase I task and should be refined in Phase II & III as needed. Identify areas of risk
for the project, procedure for monitoring the risks, and contingency plans. This is a component
of good project planning. The objective of this Section is to highlight potential issues that may
affect the successful completion of the project, and what possible solutions that you’ll put in
place to avoid/solve those issues.]

1.4.1. Areas of Risk

Table 1.3: Areas of Risk
Area of Risk Constituents
Resource
Client
Communication
Technical
Security

PSH-SYSDOC-2.1 14
AGW654 Final Year Project [A sophisticated dynamic Website]

1.4.2. Monitoring Procedure and Contingency Plan

Table 1.4: Monitoring Procedure and Contingency Plan for Risks
Risk Priority Monitoring Procedure Contingency Plan
(1=high risk,
2=medium risk,
3=low risk)

1.5. Reviews
A Client Contact Report (CCR) should be prepared during the Phase I and II formal and
informal reviews and must be included in the final SPMP.

1.5.1. Formal Reviews

Each formal review will be conducted with the attendance of the Project Team, Client, and PSH
Management. There are three formal reviews during the project development process:

 Phase II Buyoff: Design and Progress Review

 Phase II Buyoff: Prototype Review

 Phase III Buyoff: Client/Management Demo

1.5.2. Informal Reviews

Informal reviews are conducted between the Project Team and the Client. There are three
types of informal reviews:

 Phase I Buyoff: Requirements and Project Schedule

 Phase II Client Update(s): 1 minimum

 Phase III Client Update(s): 2 minimum

PSH-SYSDOC-2.1 15
AGW654 Final Year Project [A sophisticated dynamic Website]

1.5.3. Review Progress

[As you complete each Client Contact/Review, keep the original copy of the Client Contact
Report, and attach it to the final System Document as part of your SPMP.]
Table 1.5: Review Progress
Review Type Date Reviewed Components Remarks
Phase I Buyoff: CCR #:
Requirements and Project
Schedule
Phase II Buyoff: CCR #:
Design and Progress Review
Phase II Client Update 1 CCR #:
Phase II Buyoff: CCR #:
Prototype Review
Phase III Client Update 1 CCR #:
Phase III Client Update 2 CCR #:
Phase III Buyoff *:
Client/Management Demo
* Phase III Buyoff will not be documented in the SPMP

1.6. Project Schedule & Milestones

A phased project schedule is used for project development. There are three phases:

 Requirements Phase

 Design & Development Phase: Prototype Version 1

 Development & Delivery Phase: Versions 2 & 3

[Use tools such as Visio, Microsoft Project, or other drawing programs to create GANTT charts]

1.6.1. Phase I (Requirements)

[This chart is only an example. You should update it to reflect actual dates and deadlines, as
well as expand the number of items to highlight important subtasks. Depending on the SDLC
and development methodology you have chosen, create the Work Breakdown Structure (WBS)
and use tools such as Visio, Microsoft Project, or other drawing tools to create GANTT charts
as in Figure 1.3.]
Q3 05
ID Task Name Start Finish Duration
4/9 11/9 18/9 25/9

1 Project Start 9/5/2005 9/5/2005 0d

2 Assign Roles, Feasibility Study 9/5/2005 9/16/2005 10d

3 Write SRS and SPMP 9/19/2005 9/29/2005 9d

4 Client Buyoff (Phase I End) 9/30/2005 9/30/2005 0d

Figure 1.3: Phase I GANTT Chart

PSH-SYSDOC-2.1 16
AGW654 Final Year Project [A sophisticated dynamic Website]

The following team members are responsible for the following Tasks in Phase I:
Table 1.6: Phase I Task Assignments
Task ID # Responsibility Remarks
I-1 N/A
I-2 All Project Leader to coordinate individual tasks
I-3
I-4 All

1.6.2. Phase II (Design & Development: Prototype Version 1)

[This chart is only an example. You should update it to reflect actual dates and deadlines, as
well as expand the number of items to highlight important subtasks.]
Q4 05
ID Task Name Start Finish Duration
2/10 9/10 16/10 23/10 30/10 6/11 13/11 20/11 27/11 4/12 11/12 18/12 25/12

1 Phase II Start 3/10/2005 3/10/2005 0d

Refine SPMP, SRS, STD, SDD and

2 3/10/2005 4/11/2005 25d
Integration Documents

3 1st Design and Progress Review 7/11/2005 7/11/2005 0d

4 Unit Coding and Test 8/11/2005 29/12/2005 38d

5 Prototype Review (Phase II End) 2/01/2006 2/01/2006 0d

Figure 1.4: Phase II GANTT Chart

The following team members are responsible for the following Tasks in Phase II:
Table 1.7: Phase II Task Assignments
Task ID # Responsibility Remarks
II-1 N/A
II-2
II-3 All
II-4
II-5 All

1.6.3. Phase III (Development & Delivery: Versions 2 & 3)

[This chart is only an example. You should update it to reflect actual dates and deadlines, as
well as expand the number of items to highlight important subtasks.]
Q1 06 Q2 06
ID Task Name Start Finish Duration
1/1 8/1 15/1 22/1 29/1 5/2 12/2 19/2 26/2 5/3 12/3 19/3 26/3 2/4 9/4

1 Phase III Start 3/01/2006 3/01/2006 0d

2 Design/Coding 3/01/2006 23/01/2006 15d

3 Testing/Integration 24/01/2006 10/02/2006 14d

4 Client Update 1 13/02/2006 13/02/2006 0d

Revise Design/Coding/Testing/
5 13/02/2006 10/03/2006 20d
Integration

6 Final Documentation Preparation 13/03/2006 23/03/2006 9d

7 Client/Mgmt DEMO 24/03/2006 24/03/2006 0d

8 Post Mortem 24/03/2006 13/04/2006 15d

9 Project End 14/04/2006 14/04/2006 0d

Figure 1.5: Phase III GANTT Chart

PSH-SYSDOC-2.1 17
AGW654 Final Year Project [A sophisticated dynamic Website]

The following team members are responsible for the following Tasks in Phase III:
Table 1.8: Phase III Task Assignments
Task ID # Responsibility Remarks
III-1 N/A
III-2
III-3
III-4 All
III-5
III-6
III-7 All
III-8
III-9 N/A

PSH-SYSDOC-2.1 18
AGW654 Final Year Project [A sophisticated dynamic Website]

2. Software Requirements Specifications (SRS)

2.1. Engineering Requirements
[Specify the areas that will be specified in this Requirements Document. Remove subsections
that are not needed. Good Requirement statements are those that can be tested and verified.
Each Requirement should have one or more corresponding Test Cases defined in Section 4.
The Identifier for each Requirement item is used to track the Test Cases back to the respective
Requirements.]
This SRS will document the following Requirements scope for the [project system]:

 External Interfaces

 Internal Interfaces

 Capability

 Sizing, Timing and Performance

2.2. Top Level Representation

[This is a Phase I task and should be refined in Phase II & III as needed. The Top Level
System Representation can be modeled using Use-Case Diagram and Domain Model Class
Diagram. This section gives the highest level requirements for the system. Provide brief textual
descriptions of the diagram. Note that a huge system as shown in Figure 2.1 Customer Support
System (CSS) may have subsystems. However a medium size or small systems may just have
modules and sub modules. If possible do not duplicate same actors in a use case diagram
unless it cannot be avoided such as in Figure 2.1. If your system is integrated with an external
system, represent it as an actor. Some use cases can be combined such as “Create new order”
can be combined with “Update order” depending on the system. Use cases that are not related
to actors such as temporal use cases should not be included in this high-level use case
diagram. If your system is so huge, you may just represent the subsystems without drawing all
the use cases they contain.]

PSH-SYSDOC-2.1 19
AGW654 Final Year Project [A sophisticated dynamic Website]

Figure 2.6: Overall Use Case Diagram for CSS (Example)

Figure 2.7: Overall Domain Model Class Diagram for CSS (Example)

2.3. External Interfaces Requirements

[This is a Phase I task and should be refined in Phase II & III as needed. External Interfaces
refer to the I/O requirements of the system from the user perspective. Remove subsections that
are not needed.]

2.3.1. Interface [Actor 1 / XYZ System]

Identifier: [REQ-0001]

Description
Indicate the type of actor such as a person or an external system. Describe what the actor can
do briefly.

Association
List all use cases related to the actor.

GUI:
Include the storyboard or the prototype screen capture of the menus/submenus (if any).

2.3.2. Interface Order Clerk / CSS

Identifier: [REQ-0002]

Description
This actor is a person who uses CSS to manage orders made.

Association
The actor communicates with the following use cases:
 Look up item availability.
 Create new order.
 Update order.

PSH-SYSDOC-2.1 20
AGW654 Final Year Project [A sophisticated dynamic Website]

2.4. Internal Interfaces Requirements for [Subsystem/Module

1]
[This is a Phase II task and should be refined in Phase III as needed. This section documents
use cases within each sub system/module of the system including use cases that may not be
visible to the user. Use Case Diagram of the sub system/module and Domain Model Class
Diagram for Subsystem/Module 1 should be included here. Remove subsections that are not
needed. See example in Section 2.5.]

2.4.1. [Statechart Diagram 1]

Identifier: [SRS-0003]

Description
[Some systems have multiple system states that control the function of the system. Include
Statechart Diagram for the class that involves states if applicable for Use-Case 1. Remove
subsections that are not needed.]

2.4.2. [Statechart Diagram 2]

[Delete if not applicable.]

Identifier: [SRS-0004]

Description

2.4.3. [Use-Case 1]
[Exception flow identifier must be included besides normal flow if any. Alternate flow of different
scenario (if any) should be included in a separate use case description table. See example in
Section 2.5.1.]

Identifier: [SRS-0005]

Use Case Description

[Included use case description here. See example in Section 2.5.1]

GUI
[Include screen or report layout here. GUI may be modeled as a storyboard for multimedia
system or as a screen capture of the initial prototype.]

System Sequence Diagram

[Some systems have important sequence of actions that need to be specified correctly. Note
that the flow is described in the use case description (see Section 2.5.1) thus this diagram is
optional. Include the System Sequence Diagram for Use-Case 1 if applicable or necessary.
Remove subsections that are not needed.]

2.4.4. [Use-Case 2]
[Define Use-Case 2 if applicable. Remove subsections that are not needed.]

PSH-SYSDOC-2.1 21
AGW654 Final Year Project [A sophisticated dynamic Website]

Identifier: [SRS-0008]

Use Case Description

GUI

System Sequence Diagram

[Define the System Sequence Diagram for Use-Case 2 if applicable. Remove subsections that
are not needed.]

2.5. Internal Interfaces Requirements for Subsystem Order-

Entry
[This section is for additional modules (if applicable). Add/Remove sections as needed. Include
use case diagram and domain class diagram for the subsystem/module and provide also
textual description of the diagrams.]

Figure 2.8: Use Case Diagram for Order-Entry Sub system

Figure 2.9: Domain Class Diagram for Order-Entry Sub system

PSH-SYSDOC-2.1 22
AGW654 Final Year Project [A sophisticated dynamic Website]

2.5.1. Statechart Diagram for Order Item

Figure 2.10: Statechart Diagram for Order Item

2.5.2. Use-Case: Create New Order: Telephone Order

Identifier: [SRS-0003]

Use Case Description

The Create new order use case for telephone order scenario has 5 alternate flows and 4
exception flows as shown in Table 2 .9.
Table 2.9: Use Case Description for Create New Order: Telephone Order Scenario
Use Case Name: Create new order
Scenario: Create new telephone order
Triggering Event: Customer telephones RMO to purchase items from the catalog.
Brief Description: When customer calls to order, the order clerk and system verify customer
information, create a new order, add items to the order, verify payment, create the
order transaction, and finalize the order.
Actors: Telephone sales clerk
Related Use Cases: Includes: Check Item Availability
Stakeholders: Sales department: to provide primary definition.
Shipping department: to verify the information content is adequate for fulfillment.
Marketing department: to collect customer statistics for studies of buying patterns.
Preconditions: Customer must exist.
Catalog, Products, and Inventory items must exist for requested items.
Postconditions: Order and order items must be created.
Order transaction must be created for the order payment.
Inventory items must have the quantity on hand updated.
The order must be related (associated) to customer.
Normal/Alternate Flow: Actor System
1. Sales clerk answers telephone and
connects to a customer.
2. Clerk verifies customer
[REQ003-A3] information. 3.1 Create a new order.
3. Clerk initiates the creation of a new
order.
4. Customer requests an item be
[REQ003-A5] added to the order. 5.1 Display item information.
5. Clerk verifies the item (Check item
[REQ003-A6] availability use case). 6.1 Add an order item.
6. Clerk adds items to the order.
7. Repeat steps 4, 5, 6 until all items
[REQ003-A8] are added to the order. 8.1 Complete order.
8. Customer indicates end of order, 8.2 Complete totals.
[REQ003-A9] clerk enters end of order. 9.1 Verify payment.

PSH-SYSDOC-2.1 23
AGW654 Final Year Project [A sophisticated dynamic Website]

9. Customer submits payment, clerk 9.2 Create order transaction

enters amount. 9.3 Finalize order.
Exception Flow:
[SRS-0003-E2.1] 2.1 If customer does not exist, then the clerk pauses this use case and invokes
Maintain customer information use case.
[SRS-0003-E2.2] 2.2 If customer has a credit hold, then clerk transfers the customer to a customer
service representative.
[SRS-0003-E4.1] 4.1 If an item is not in stock, then customer can
a. choose not to purchase item, or
b. request item be added as a back-ordered item.
[SRS-0003-E9.1] 9.1. If customer payment is rejected due to bad-credit verifications, then
a. order is canceled, or
b. order is put on hold until check is received.

System Sequence Diagram: Telephone Order Scenario

[You may include both normal and exception flows of a use case in a single sequence diagram
if the diagram is not cluttered. Some flows have alternate flows. The system sequence diagram
below shows normal flow between the actor and the system without including the exception
flows for the scenario create new order using telephone order. It is advised to represent
different alternate flow or exception flow in a different diagram if it is too cluttered to be in a
single diagram. This also applies to different scenarios of a use case, which should be in
different sections too. Hence you will need to draw a new system sequence diagram for
different scenario of Create New Order.]

Figure 2.11: Use Case Description for Create New Order: Telephone Order Scenario

2.5.3. [Use-Case 4]
[Define Use-Case 4 if applicable. Remove subsections that are not needed.]

Identifier: [SRS-0009]

Use Case Description

GUI

System Sequence Diagram

PSH-SYSDOC-2.1 24
AGW654 Final Year Project [A sophisticated dynamic Website]

2.6. Non-Functional Requirements

2.6.1. Space Requirement
[Indicate the size limitations for the spaces of servers, hard disks or storage medias required, if
any, for each module in the system. Remove subsections that are not needed.]
The following table indicates the system response time limits for processing inputs:
Table 2.10: System Sizing Limitations
Module Description Size

2.6.2. Performance Requirement

[Indicate the response time or performance targets for input and output, if any, for the system.
Remove subsections that are not needed.]
The following table indicates the system response time limits for processing inputs:
Table 2.11: System Timing Targets
Response Time Input Description Output

2.6.3. Other Relevant Non-Functional Requirement

[Indicate processing performance goal, if any. Remove this subsection if there is no other
relevant non-functional requirement such as usability, delivery, and safety.]
The final system will have to meet the following performance goals:
Table 2.12: System Performance Goals
Metric Description Goal
Throughput Number of sustained transactions per Min. 5,000 TPS
second (TPS)
Scalability Number of concurrent transaction Min. 1,000
requests simultaneous
transactions
Usability

PSH-SYSDOC-2.1 25
AGW654 Final Year Project [A sophisticated dynamic Website]

3. Software Design Description (SDD)

3.1. Storyboard
[This is a Phase II task and should be refined in Phase III as needed. Define Storyboard (if
relevant) used in Multimedia Projects. Remove this section if not applicable.]

3.2. High Level Design

[This is a Phase II task and should be refined in Phase III as needed. Define High Level Design
for overall system architecture including integration with existing system if any and include the
diagram. If your system is standalone system, you may just include the link of the hardware,
software, and main components in the system.]

Figure 3.12: Network Diagram of CSS Architecture

3.2.1. System Architecture

[Describe and include Design Class Diagram. This section indicates the hierarchy and
dependency relationships among the various classes in the various modules/subsystems.]

Figure 3.13: Design Class Diagram for CSS

PSH-SYSDOC-2.1 26
AGW654 Final Year Project [A sophisticated dynamic Website]

3.2.2. System Packages

[Describe and include System Level Package Diagram. This section indicates the inter-
package relationships among the various packages. You may have one layer package diagram
that focuses on Domain Layer only and create sub packages for different modules/subsystems.
Normally a module will be a package that contains all the related classes in the module.
Depending on the drawing tool you use the package diagram may look like Figure 3.3. This
diagram is generated using Rational Rose. Note that Package3 is actually sub package of
Package2. You may draw in a nested way if the drawing tool allows you to do so.]]

Package3
Package1 Package2
(from Package2)
+ Class1 + Class3
+ Class5
+ Class2 + Class4
+ Class6

Figure 3.14: Package Diagram

3.3. Integration Interfaces

[This is a Phase II task and should be refined in Phase III as needed. Define inter-package
interfaces for system to specify the I/O of parameters passed and return values (if any)
between packages, and which class in Package 1 interacts with which class in Package 2, etc.
This information is important for implementing stub routines for unit testing prior to actual
System Module (package) Integration]

3.3.1. [Package 1] I/O Interfaces

Package1 Package2
+ Class1 + Class3
+ Class2 + Class4

Figure 3.15: Inter-Package I/O Parameters for [Package 1]

Input Parameters
Class: Class1
Parameter type: int, int
Parameter name: param1, param2

Output Parameters
Class: Class4
Return type: String

3.3.2. [Package 2] I/O Interfaces

[Define the Pacage 2 I/O Interfaces if applicable. Remove if not needed.]

Input Parameters

Output Parameters

PSH-SYSDOC-2.1 27
AGW654 Final Year Project [A sophisticated dynamic Website]

3.4. Detailed Design for [Package 1]

[Describe Low Level Design for each Module/Package using chosen Design Notation. E.g.,
UML specified in Section 1.1.4. This corresponds to the internal classes, sequence diagrams,
and statechart diagrams/pseudocode/flowcharts within the various Packages defined in Section
3.2. Some project types will emphasize certain aspects of the detailed design. E.g., Sequence
Diagrams/Flowcharts will be more important in Network/Systems projects. Remove any
subsections that are not applicable. Note that to describe operations/methods you may use
either statechart diagram/pseudocode/flowcharts. It is better to use statechart diagram if you
use UML notation. Stereotype can be entity, control, boundary or data access. Refer Satzinger,
2005. See example in Section Error: Reference source not found. Include all sequence
diagrams based on use cases in Chapter 2 and then describe all classes in package 1.]

3.4.1. Detailed Sequence Diagram: Create New Order

[Include detailed sequence diagrams for all use cases in package 1 and its textual description.
This must correspond to system sequence diagrams discussed in Chapter 2.]

Identifier: [SRS-0003]

Telephone Order Scenario [SRS-0003-A1]

Figure 3.16: Detailed Sequence Diagram for Telephone Order Scenario

 Order clerk starts the order via OrderHandler.
 OrderHandler creates the order for the Customer.
 Once order is created order clerk will repeatedly add all items for the order.
 …

3.4.2. Class OrderItem

OrderItem
productID : int
inventoryID : int
description : string
price : float
quantity : integer
backOrderStatus : string

createOrderItem(catalogID, productID, size, quantity)

Figure 3.17: Class OrderItem

PSH-SYSDOC-2.1 28
AGW654 Final Year Project [A sophisticated dynamic Website]

Stereotype:
Entity

Responsibility:
This class is responsible to keep track all order items.

Attributes:
 productID: int
 inventoryID: int
 description: string
 price: float
 quantity: integer
 backOrderStatus: string
- unique ID of each product
- unique ID of inventory
- describe the order item
- price of each item
- quantity of items ordered
- status of back order

Operations/Methods:
 CreateOrderItem(catalogID, productID, size, quantity)

3.4.3. State Transition Diagrams

Figure 3.18: Statechart for OrderItem

3.4.4. CreateOrderItem Flowchart / Pseudocode

Responsibility:
This method creates order items if item exists and quantity and size are in stock

Input Parameter(s):
 catalogID, productID, size, quantity

Output Parameter(s):
 OrderStatus

Pre Condition:

PSH-SYSDOC-2.1 29
AGW654 Final Year Project [A sophisticated dynamic Website]

Description:
Do
If (catalogID exists && productID exists),
and if (quantity <= productID.quantity && size == productID.size) Then
Commit Order Item
Else
Display Error
End

Post Condition:

3.5. Detailed Design for [Package 2]

[Define if applicable. Remove this section if not needed.]

3.5.1. Detailed Sequence Diagrams

[Define if applicable. Remove if not needed.]

3.5.2. [Class Design 1]

Stereotype:

Responsibility:

Attributes:

Operations/Methods:

3.5.3. [Class Design 2]

Stereotype:

Responsibility:

Attributes:

Operations/Methods:

3.5.4. State Transition Diagrams

[Define if applicable. Remove if not needed.]

3.5.5. Flowchart / Pseudocode

[Define if applicable. Remove if not needed.]

Responsibility:

Input Parameter(s):

Output Parameter(s):

PSH-SYSDOC-2.1 30
AGW654 Final Year Project [A sophisticated dynamic Website]

Pre Condition:

Description:

Post Condition:

PSH-SYSDOC-2.1 31
AGW654 Final Year Project [A sophisticated dynamic Website]

4. Software Test Documentation (STD)

4.1. System Test Cases
[This is a Phase II activity, and should be refined in Phase III. Define test cases for the system
SRS External Interfaces Requirement statements. There should be at least one Test Case for
each High Level Requirement specified in Sections 2.1,2.2, and 2.3 for proper verification that
the developed system meets the client’s requirements. The Traceability Reference is obtained
from the respective requirement specification in Sections 2.1,2.2, and 2.3.]

4.1.1. [Test Case 1]

Identifier: [STD-0001]

Requirement Traceability Reference: [REQ-0001]

Description
{Example: All Date Inputs to system must be validated. For example, Feb 29 is only allowed in
leap years, while invalid dates such as Jan 32, Feb 30, etc. are not accepted as valid inputs}

Use Case/ Test Case Initialization Test Input Expected Test

Scenario Result Procedure
SRS-0001-E1.1 STD-0001-
E1.1
SRS-0001-A1 STD-0001-A1

4.1.2. [Test Case 2]

[Define if applicable. Remove if not needed.]

Identifier: [STD-0002]

Requirement Traceability Reference: [REQ-0002]

Description

Use Case/ Test Case Initialization Test Input Expected Test

Scenario Result Procedure
SRS-0002-A1 STD-0002-A1
SRS-0002-E1.1 STD-0002-
E1.1

4.2. Unit Test Cases for [Module 1]

[This is a Phase III activity although it would be better if started in Phase II. Define test cases
for the unit SRS Internal Interfaces Requirement statements. There should be at least one Test
Case for each Low Level Requirement specified in Sections 2.4 onwards related to Low Level
Requirements. The Traceability Reference is obtained from the respective requirement
specification in Sections 2.4 onwards related to Low Level Requirements.]

PSH-SYSDOC-2.1 32
AGW654 Final Year Project [A sophisticated dynamic Website]

4.2.1. [Test Case 1]

Identifier: [STD-0003]

Requirement Traceability Reference: [SRS-0003, SRS-0004]

Description

4.2.2. [Test Case 2]

[Define if applicable. Remove if not needed.]

Identifier: [STD-0004]

Requirement Traceability Reference: [SRS-0005]

Description

4.3. Test Cases for Subsystem Order-Entry

4.3.1. Test Case: Create New Order [STD-0003]

Requirement Traceability Reference: [SRS-0003]

Use Case/ Test Case Initialization Test Input Expected Result

Scenario
SRS-0003- STD-0003-  Click button new  Existing  accountNo found.
A3 A3 accountNo
SRS -0003- STD-0003-  Check item  itemNo  Item info listed.
A5 A5
SRS -0003- STD-0003-  Add items  catalogID, prodID,  New order added.
A6 A6 repeatedly size, quantity
SRS -0003- STD-0003-  Click button -  paymentAmt output.
A8 A8 complete
SRS -0003- STD-0003-  Enter amount -  Payment recorded.
A9 A9 paid
SRS-0003- STD-0001-  Click button new  Not existing  Display message to
E2.1 E2.1 accountNo add customer.

SRS-0003- STD-0001-  Click button new.  accountNo found.  Display credit card
E2.2 E2.2 info.

SRS-0003- STD-0003-  New order  accountNo found.  Display message

E4.1 E4.1 added.  catalogID, prodID, item not in stock.
size, quantity.
 Cancel order.
 Add back-order.  Order item added.

SRS-0003- STD-0003-  Pay using credit  Credit card no.  Order cancelled.
E9.1 E9.1 card.
 Pay using check.  Order on hold.

PSH-SYSDOC-2.1 33
AGW654 Final Year Project [A sophisticated dynamic Website]

5. Software Test Report (STR)

5.1. System Test Reports
[This is a Phase III activity. Report results for the system STD defined in Section 4.1. Each
System Test Case must have a corresponding Test Report.]

5.1.1. [Test Report 1]

Identifier: [STR-0001]

Test Case Traceability Reference: [STD-0001]

Result
{Example: System was able to validate date inputs as specified in test case. Invalid dates
entered will cause an error alert dialog box to be displayed.}

Test Case Success Failure/Error Remark

STD-0001-E1.1 Yes None -
STD-0001-A1 Can add only Cannot edit -

5.1.2. [Test Report 2]

[Define if applicable. Remove if not needed.]

Identifier: [STR-0002]

Test Case Traceability Reference: [STD-0002]

Result
Test Case Success Failure/Error Remark
STD-0002-A1
STD-0002-E1.1

5.2. Unit Test Reports

[This is a Phase III activity. Report results for the unit STD defined in Section 4.2 onwards.
Each Unit Test Case must have a corresponding Test Report.]

5.2.1. Create New Order

Identifier: [STR-0003]

Test Case Traceability Reference: [STD-0003]

PSH-SYSDOC-2.1 34
AGW654 Final Year Project [A sophisticated dynamic Website]

Result
Test Case Success Failure/Error Remark
STD-0003-A3 Yes None -
STD-0003-A5 Yes None -
STD-0003-A6 Yes None -
STD-0003-A8 Yes None -
STD-0003-A9 Yes None -
STD-0003-E2.1 No Message not displayed -
STD-0003-E2.2 Yes None -
STD-0003-E4.1 Partial Order item not added Check temporal event
after the stock available
STD-0003-E9.1 Yes None -

5.2.2. [Test Report 1]

Identifier: [STR-0004]

Test Case Traceability Reference: [STD-0004]

Result

PSH-SYSDOC-2.1 35
AGW654 Final Year Project [A sophisticated dynamic Website]

6. REFERENCES
Satzinger, J. W., Jackson, R. B. and Burd, S. D., Object-Oriented Analysis and Design with the
Unified Process, Thomson, 2005.

PSH-SYSDOC-2.1 36