Group Project b

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)

GSBUniversiti Sains Malaysia

11800 USMPenang, Malaysia

Session 2009/2010

PSH-SYSDOC-2.1

AGW654 Final Year Project [A sophisticated dynamic Website]

Document Revision HistoryRevision Date Updated by Description

PSH-SYSDOC-2.1 ii


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

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

PSH-SYSDOC-2.1 iii


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

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

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

PSH-SYSDOC-2.1 iv


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


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


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


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

Vistana Hotel’s website

Accommodation Amenities Meetings & Events

Reservation Capture Guest’s Contact/Autoresponder

Dining/Nightlife Entertainment Media Experience/Testimonial

Mobile Site


Figure 1.1: Complete System Module Breakdown

1.1.2. Development Methodology

1.1.3. Software LifecycleThis project uses the Rapid Prototyping Lifecycle with Versioning (Spiral Model) for the development planning and scheduling.

Client Requirements

Specification ofRequirements

Analysis

Validation

AlternativeSolutions

TechnicalSpecifications

Working System

Operating System

Validation System Design

Validation

Testing

Installation & Maintenance

Meeting

Validation

Figure 1.2: Rapid Prototyping Lifecycle with Software Versioning

PSH-SYSDOC-2.1 9


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.3.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.3.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.

3 SPECIFIC REQUIREMENTS

PSH-SYSDOC-2.1 10


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 Developing Value added

Static website

Make data warehouse Promotion (discount customers)

Product bundle(Exp: free breakfast for one night

stay)

Possibility of client feedback

Real time direct communicationInvest on royal

customers and Need-based customers

Automat responsibility Confirm of room atomically

Boring websiteUse better color and

design attractive websiteClient surf more time in

siteLive music Make good sense about

hotelDon’t have keyword Expand html code and

make keywordFind new customer via

search engineCan’t pay online Possibility of paying at the

booking timeGive customer more

confidentialDon’t have link to other

websiteLink to tourist website Find new customer and make

more traffic on webDon’t present the feature of

hotel in homepageUse flash(with logical

pictures) and add essential data to homepage

Find more Need-based customers

Don’t have any group in famous social website like

facebook

Make a group in facebook and invite our customer to become

our fan via our website

Find fans from customers and build more brand awareness

Table 1-Developing

1.1.3.3 Design-Our design will look like this prototype : http://wansharinee.com/HeartFeltHotel/

PSH-SYSDOC-2.1 11

http://wansharinee.com/HeartFeltHotel/


For Mobile site :

1.1.3.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.3.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 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

PSH-SYSDOC-2.1 12


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.com2) forum marketing3) marketing thru social nworking sites such as fb, myspace,4) promote to social bookmarking sites such as digg.com, propeller.com. stumbleupon.com5) videomarketing- utube,metacafe6) marketing thru groups- google, msn, yahoo7)image storing side- flickr.com8)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.3.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 NotationDescribe 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 StandardVistana 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 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 AssignmentsEach team member is a Developer. In addition, the following roles are assigned to the respective team members.

Table 1.1: Project Team Role Assignments

PSH-SYSDOC-2.1 13

http://flickr.com/

http://stumbleupon.com/

http://propeller.com/

http://digg.com/

http://goarticles.com/

http://ezinearticles.com/


Role Team MemberProject LeaderQuality 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 AllocationNo 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 ResourcesNil

1.3.3. Software and Operating System Resource SpecificationsWe 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 RiskTable 1.3: Areas of Risk

Area of Risk ConstituentsResourceClientCommunicationTechnicalSecurity

1.4.2. Monitoring Procedure and Contingency PlanTable 1.4: Monitoring Procedure and Contingency Plan for Risks

Risk Priority (1=high risk, 2=medium risk, 3=low risk)

Monitoring Procedure Contingency Plan

PSH-SYSDOC-2.1 14


1.5. ReviewsA 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 ReviewsEach 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 ReviewsInformal 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


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 RemarksPhase I Buyoff: Requirements and Project Schedule

CCR #:

Phase II Buyoff: Design and Progress Review

CCR #:

Phase II Client Update 1 CCR #:Phase II Buyoff: Prototype Review

CCR #:

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 & MilestonesA 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.]

Figure 1.3: Phase I GANTT Chart

PSH-SYSDOC-2.1 16


The following team members are responsible for the following Tasks in Phase I:Table 1.6: Phase I Task Assignments

Task ID # Responsibility RemarksI-1 N/AI-2 All Project Leader to coordinate individual tasksI-3I-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.]

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 RemarksII-1 N/AII-2II-3 AllII-4II-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.]

Figure 1.5: Phase III GANTT Chart

PSH-SYSDOC-2.1 17


The following team members are responsible for the following Tasks in Phase III:Table 1.8: Phase III Task Assignments

Task ID # Responsibility RemarksIII-1 N/AIII-2III-3III-4 AllIII-5III-6III-7 AllIII-8III-9 N/A

PSH-SYSDOC-2.1 18


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.]

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

PSH-SYSDOC-2.1 19


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]

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

AssociationList 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]

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

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

PSH-SYSDOC-2.1 20


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.]


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.]


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.]


Use Case Description

PSH-SYSDOC-2.1 21


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


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



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 orderScenario: Create new telephone orderTriggering 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 clerkRelated Use Cases: Includes: Check Item AvailabilityStakeholders: 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

[REQ003-A3]

[REQ003-A5]

[REQ003-A6]

[REQ003-A8]

[REQ003-A9]

1. Sales clerk answers telephone and connects to a customer.

2. Clerk verifies customer information.3. Clerk initiates the creation of a new

order.4. Customer requests an item be

added to the order.5. Clerk verifies the item (Check item

availability use case).6. Clerk adds items to the order.7. Repeat steps 4, 5, 6 until all items

are added to the order.8. Customer indicates end of order,

clerk enters end of order.9. Customer submits payment, clerk

enters amount.

3.1 Create a new order.

5.1 Display item information.

6.1 Add an order item.

8.1 Complete order.8.2 Complete totals.9.1 Verify payment.9.2 Create order transaction9.3 Finalize order.

PSH-SYSDOC-2.1 23


Exception Flow:[SRS-0003-E2.1]

[SRS-0003-E2.2]

[SRS-0003-E4.1]

[SRS-0003-E9.1]

2.1 If customer does not exist, then the clerk pauses this use case and invokes Maintain customer information use case.2.2 If customer has a credit hold, then clerk transfers the customer to a customer service representative.4.1 If an item is not in stock, then customer can

a. choose not to purchase item, orb. request item be added as a back-ordered item.

9.1. If customer payment is rejected due to bad-credit verifications, thena. order is canceled, orb. 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.]



GUI

System Sequence Diagram

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:

PSH-SYSDOC-2.1 24


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 GoalThroughput Number of sustained transactions per

second (TPS)Min. 5,000 TPS

Scalability Number of concurrent transaction requests

Min. 1,000 simultaneous transactions

Usability

PSH-SYSDOC-2.1 25


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


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.]]

Package1

+ Class1+ Class2

Package2

+ Class3+ Class4

Package3

(from Package2)+ Class5+ 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

+ Class1+ Class2

Package2

+ Class3+ Class4

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

Input ParametersClass: Class1Parameter type: int, intParameter name: param1, param2

Output ParametersClass: Class4Return 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

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

PSH-SYSDOC-2.1 27


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.]


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 : intinventoryID : intdescription : stringprice : floatquantity : integerbackOrderStatus : string

createOrderItem(catalogID, productID, size, quantity)

Figure 3.17: Class OrderItem

Stereotype:Entity

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

PSH-SYSDOC-2.1 28


Attributes: productID: int - unique ID of each product inventoryID: int - unique ID of inventory description: string - describe the order item price: float - price of each item quantity: integer - quantity of items ordered backOrderStatus: string - 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


Description:Do

If (catalogID exists && productID exists),and if (quantity <= productID.quantity && size == productID.size) Then

Commit Order ItemElse

Display ErrorEnd

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


Pre Condition:

Description:

Post Condition:

PSH-SYSDOC-2.1 31


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/ Scenario

Test Case Initialization Test Input Expected Result

Test 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.]


Requirement Traceability Reference: [REQ-0002]

Description

Use Case/ Scenario


Test Procedure

SRS-0002-A1 STD-0002-A1SRS-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


4.2.1. [Test Case 1]


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

Description

4.2.2. [Test Case 2][Define if applicable. Remove if not needed.]


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/ Scenario


SRS-0003-A3

STD-0003-A3

Click button new Existing accountNo

accountNo found.

SRS -0003-A5

STD-0003-A5

Check item itemNo Item info listed.

SRS -0003-A6

STD-0003-A6

Add items repeatedly

catalogID, prodID, size, quantity

New order added.

SRS -0003-A8

STD-0003-A8

Click button complete

- paymentAmt output.

SRS -0003-A9

STD-0003-A9

Enter amount paid

- Payment recorded.

SRS-0003-E2.1

STD-0001-E2.1

Click button new Not existing accountNo

Display message to add customer.

SRS-0003-E2.2

STD-0001-E2.2

Click button new. accountNo found. Display credit card info.

SRS-0003-E4.1

STD-0003-E4.1

New order added.

Cancel order. Add back-order.

accountNo found. catalogID, prodID,

size, quantity.

Display message item not in stock.

Order item added.

SRS-0003-E9.1

STD-0003-E9.1

Pay using credit card.

Pay using check.

Credit card no. Order cancelled.

Order on hold.

PSH-SYSDOC-2.1 33


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 RemarkSTD-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.]



ResultTest Case Success Failure/Error RemarkSTD-0002-A1STD-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



PSH-SYSDOC-2.1 34


ResultTest Case Success Failure/Error RemarkSTD-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

after the stock availableCheck temporal event

STD-0003-E9.1 Yes None -

5.2.2. [Test Report 1]



Result

PSH-SYSDOC-2.1 35


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

Group Project b

Documents