Inkjet & Toner Information
and Ordering Website
Software Requirements Specification (SRS)
For ICT Student Projects
University of Ballarat
Team Members:
Chris Allely
Jeremy Egan
Michael Ellery
Daniel Meade
Document Version: 4
Release Date: 05/05/2006
Any printed versions are considered uncontrolled versions of this document.
Table of Contents
Revision History ........................................................................................................................... 5
1.0 Project Overview .................................................................................................................... 6
1.1 Identification ....................................................................................................................... 6
1.2 Document Overview ........................................................................................................... 7
1.2.1 Purpose and contents of this document ....................................................................... 7
1.2.2 Security and privacy considerations associated with use of this document ................. 8
1.3 System Overview................................................................................................................ 9
1.3.1 General nature of the system to be developed ............................................................ 9
1.3.2 System objectives ...................................................................................................... 10
1.3.3 History of system development .................................................................................. 11
1.3.4 Operation and maintenance ....................................................................................... 11
1.3.5 Parties Involved ......................................................................................................... 12
1.3.6 Current and planned operating sites .......................................................................... 13
1.4 Current Business Processes ............................................................................................ 14
1.5 Constraints ....................................................................................................................... 14
1.6 Evaluating Project Success .............................................................................................. 15
1.7 Document Structure.......................................................................................................... 16
2.0 Definitions and Acronyms .................................................................................................... 18
Acronyms ............................................................................................................................... 18
Definitions............................................................................................................................... 18
3.0 General Description ............................................................................................................. 19
3.1 Product Functions............................................................................................................. 19
3.2 User Characteristics ......................................................................................................... 21
3.3 Assumptions and Dependencies ...................................................................................... 21
3.4 Product Outlook ................................................................................................................ 22
3.4.1 User Interfacing.......................................................................................................... 22
3.4.2 Memory Constraints ................................................................................................... 29
3.4.3 Operations ................................................................................................................. 29
3.4.4 Adaptation Requirements........................................................................................... 30
3.5 User Base ......................................................................................................................... 30
3.6 General Design Constraints ............................................................................................. 31
3.7 Project Feasibility ............................................................................................................. 32
4.0 Specific Requirements ......................................................................................................... 33
Version: 4 Date: 05/05/2006 2
4.1 External Interface Requirements ...................................................................................... 33
4.1.1 User Interfaces ........................................................................................................... 33
4.1.2 Interface Storyboards ................................................................................................. 34
4.1.3 Hardware Interfaces ................................................................................................... 43
4.1.4 Software Interfaces .................................................................................................... 43
4.1.5 Communications Protocols ........................................................................................ 44
4.1.6 Site Map ..................................................................................................................... 45
4.2 Database Requirements ................................................................................................... 47
4.2.1 Entity-Relationship Diagram....................................................................................... 47
4.2.2 Explanatory Notes to the Entity-Relationship Diagram .............................................. 48
4.2.3 Database Schema ..................................................................................................... 49
4.3 Operating Requirements .................................................................................................. 51
4.3.1 Client-side .................................................................................................................. 51
4.3.2 Server-side................................................................................................................. 51
4.4 Software Requirements .................................................................................................... 51
4.4.1 Client-side .................................................................................................................. 51
4.4.2 Server-side................................................................................................................. 52
4.5 Specific Functional Requirements .................................................................................... 53
4.5.1 Automatically load stocks (S1) ................................................................................... 53
4.5.2 Verify users (S2) ........................................................................................................ 54
4.5.3 Allow users to sign up (S3) ........................................................................................ 54
4.5.4 Provide product listings (S4) ...................................................................................... 54
4.5.5 Provide search functions (S5) .................................................................................... 55
4.5.6 Process orders (S6, S11) ........................................................................................... 55
4.5.7 Provide help functions (S7) ........................................................................................ 55
4.5.8 Security (S8) .............................................................................................................. 56
4.5.9 Allow for manual updates (S9) ................................................................................... 56
4.5.10 Provide contact information (S10) ............................................................................ 57
4.5.11 Administration system (S12) .................................................................................... 57
4.6 Performance Requirements .............................................................................................. 58
4.6.1 Reliability.................................................................................................................... 58
4.6.2 Availability .................................................................................................................. 58
4.6.4 Application Level Security .......................................................................................... 59
4.6.5 Maintainability ............................................................................................................ 59
4.6.6 Speed......................................................................................................................... 60
Version: 4 Date: 05/05/2006 3
4.7 Quality Requirements ....................................................................................................... 61
4.8 Training Requirements ..................................................................................................... 62
5.0 Copyright Issues .................................................................................................................. 63
6.0 Project Budget ..................................................................................................................... 64
6.1 Initial Fixed Costs (Start up cost) ...................................................................................... 64
6.2 Project Staffing Costs ....................................................................................................... 64
6.3 Annual Reoccurring Costs ................................................................................................ 64
6.4 Expected Financial Benefits ............................................................................................. 65
6.5 NPV Analysis .................................................................................................................... 66
Appendices ................................................................................................................................ 67
Appendix 1: Business Flowchart ............................................................................................ 67
Appendix 2: Use Case Model ................................................................................................. 68
Appendix 3: Activity Diagrams ................................................................................................ 69
Appendix 4: Traceability Matrix .............................................................................................. 71
Appendix 5: Supplier Stock Sheet .......................................................................................... 72
References................................................................................................................................. 73
Texts....................................................................................................................................... 73
Standards ............................................................................................................................... 73
Internet Material ..................................................................................................................... 73
Client Sign-Off............................................................................................................................ 74
Version: 4 Date: 05/05/2006 4
Revision History
VERSION: REVISION DATE: PAGES UPDATED: CHANGES MADE: AUTHOR:
1 31/3/2006 All All sections of document Jeremy
proof read and finalised for
submission.
2 21/4/2006 All Fixed typing/grammatical All Team Members
mistakes, and rephrasing of
some key points.
Addition of revision history,
costing and budgeting
information.
Updated Section 2.1 to fall in
line with Traceability Matrix.
Prioritised and updated
functionality in Section 3.5
Added Appendix 5
containing traceability
matrix.
Removed inconsistencies
within document.
3 28/4/2006 All Prioritised and tabled Chris, Jeremy.
functional requirements in
section 3.5.
Added descriptions to
requirements in section 3.5.
Added use case 7 and 8 and
use case diagram.
Updated user base in
section 2.5.
Added section 3.6, 3.7, 3.8
containing performance,
quality requirements and
training requirements
Added section 5 containing
the project budget.
Added references section at
end of document.
4 5/5/06 All Updated section numbers. All Team Members.
Moved appendix to Section
2.
Updated Section 1.3.2 and
added Section 1.6 and 1.7.
Updated Section 1.3.6 to
reflect field trip.
Updated Use Case Model.
Added exceptions and
database requirements to
sue cases.
Rename and updated use
case model.
Created site map Section
4.1.6.
Created storyboards Section
4.1.2.
Updated budget in section 6.
Version: 4 Date: 05/05/2006 5
1.0 Project Overview
1.1 Identification
This document applies to the „Inkjet & Toner Information and Ordering Website‟ project, also
referred to as ITIOW. The purpose of this project is to develop an eCommerce solution for a
small Ballarat business known as „Inkjet & Toner Cartridge Recycling‟.
Version: 4 Date: 05/05/2006 6
1.2 Document Overview
1.2.1 Purpose and contents of this document
This document is made available to all project stakeholders and defines what the end product
will and will not do. The document outlines the project scope, characteristics, functional and
non-functional requirements.
The purpose of this document is to comprehensively and completely define the product to be
delivered and the document‟s success is determined by this. If another party was to pick up and
complete this project, this document should provide enough information for them to create an
identical product.
In addition to the above, this document acts as a contract between the project team and the
client. It allows the client and the project team to easily find the requirements of the final
product.
It must be noted that this document is a „live‟ document and is constantly subject to revision
based on changes and/or elaboration of the client‟s requirements as the project evolves.
Revisions of this document may occur at any time, with the latest version being made available
online at the project website.
Version: 4 Date: 05/05/2006 7
1.2.2 Security and privacy considerations associated with use of this document
This document is for a commercial business and as such may contain data which is considered
confidential or sensitive in nature. It is expected that care will be taken when divulging
information to third parties and consent received from the client where appropriate.
This document is intended to be made available for authorised users only and includes (but is
not limited to) the project team, the project team supervisor, the „Project 1‟ unit coordinator and
other project groups for learning purposes.
While every effort will be made to keep sensitive data separate from this document, some data
may need to be included in order to adequately define the project‟s requirements.
Version: 4 Date: 05/05/2006 8
1.3 System Overview
The following sections are in relation to the new system to be developed.
1.3.1 General nature of the system to be developed
The system to be developed will be in the form of a business website which will provide
customers of the business with information they need in order to make informed decisions about
buying the various products offered by the company, and additionally for the promotion of
specials and new product lines.
A database will be incorporated into the website, and allow the customer to view a listing of
available products, alongside current inventory levels for consumable stock, links to product
brochures/information, and estimated delivery times.
This website, through the database, will also allow customers to create a profile so that they
may order any products that they require online. Customers will be authenticated by mandatory
details such as a password. Customers of the website will be able to submit orders for products
they require and the system will notify the business by email. A confirmation and payment
system is not currently required by the client as this will rely on existing business processes,
however, the confirmation and payment system functionality may be required by the University
of Ballarat in order to give the project sufficient scope. Further clarification will be obtained as
the project develops.
The website will provide an administrative section which will allow items to be added, altered
and deleted. It is essential that this interface is simple, efficient (not too time consuming) and
easy to use. Any language used should be in plain English and contain minimum technical
jargon. In addition to this, the system must be capable of importing data from supplier stock
sheets shown in Appendix 5, and applying mark-up formulae to determine the selling price. The
formulae used must be flexible and the system prices must be able to be overridden manually.
As there is no eCommerce solution currently in place, a suitable web/database server will need
to be set up and configured. This will also require the reconfiguration of existing network
facilities at the installation site. The purchase of the server falls outside the scope of the project,
although advice may be given to the client to ensure that an appropriate server is purchased.
Version: 4 Date: 05/05/2006 9
In addition to the above, the system needs to be recoverable in case of a disaster. A CD and
accompanying documentation such as installation instructions and backup procedures will be
included in the final product as well as onsite user training during the final phases of
development.
While the creation of the website gives rise to conducting business around the world, the client
has expressed to the project team that the business will still remain limited to the local area
(Ballarat and surrounding areas).
Note: Refer to Section 1.5 and Section 3.7 for project constraints. Also refer to Section 4
regarding specific project requirements.
1.3.2 System objectives
The following list outlines the objectives of the system:
1. Provide a web presence
In today‟s day and age, most businesses have websites, and creating one for Inkjet &
Toner will allow them to keep up with (or be one step ahead of) competitors. Providing a
website will enable Inkjet and Toner Cartridge Recycling to increase its exposure and
potential customer base by opening its doors to the world.
2. Attract new customers
Providing a website will enable Inkjet & Toner Cartridge Recycling to reach customers
that were otherwise unavailable through geographical restrictions, or attract new
customers by providing a better service. This will improve revenue and thus profit.
3. Improve service for existing customers
The system will assist in the preservation of the current customer base by providing
another means for existing customers to interact with the company. The website will
enable information and ordering facilities to be available on demand 24/7.
Version: 4 Date: 05/05/2006 10
4. Improve efficiency
The website will help automate the ordering procedure and make business more
efficient, thus creating more time to deal with (additional) customers and hence increase
income.
5. Provide information
The website will provide information and support to customers who are unsure about
what product to buy for example. This will help create a sense of loyalty and assist in
maintaining the existing customer base and the attraction of new customers.
Note: Each objective listed above is satisfied by the product functions contained within Section
3.1. Success criteria used in evaluating project objectives in contained within Section 1.6.
1.3.3 History of system development
There have been no previous attempts in creating a website for this business and as such there
are no legacy systems that development can be based around. Inkjet & Toner Cartridge
Recycling has been operating for seven years and the proposed system will aim to complement
the existing business processes.
1.3.4 Operation and maintenance
The operation of the system will be done by the client (Mr Neil Patterson). The client will provide
(and remain responsible for maintaining) an adequate connection to the Internet at the
installation premises once the system is operational. The system will be easy to use and be self
explanatory. A web interface will be made available for adding new products, deleting old lines,
changing prices and other related administration functions.
The client will also be responsible for maintaining the system, which includes managing the
server, updating data/product information, and creation of backups. Additionally, the client must
be able to recover the system in the case that the server crashes.
Version: 4 Date: 05/05/2006 11
1.3.5 Parties Involved
1.3.5.1 Project Sponsor
The project sponsor is Mr Neil Patterson. This project is a student project and as such there will
be no cost for the actual project. The project sponsor will be responsible for extra costs
incurred, including (but not limited to) domain name registration and purchase of required
hardware. Refer to Section 6.0.
1.3.5.2 Acquirer
The project acquirer is the same as the project sponsor above in Section 1.3.5.1.
1.3.5.3 Users
Server Side
Mr Neil Patterson
Mr Neil Patterson will use the website to manage the database containing the stock,
manage customer‟s accounts and perform maintenance. At this stage of the project, the
scope is limited to the Ballarat and district area and does not include a payment system
(for more information, see Section 1.3.1). There has been no suggestion of significant
future expansion as Neil wants to keep the business local and as such there is no set
requirement for scalability.
Client Side
Existing Customers
Existing customers will be able to view information about the products offered and submit
orders.
New Customers
New customer will be able to view the products offered and can find information on how
to contact the business, or apply for an account.
Version: 4 Date: 05/05/2006 12
1.3.5.4 Developers
The project team will be responsible for developing the project. The team members are outlined
below:
Chris Allely
Jeremy Egan
Michael Ellery
Daniel Meade
1.3.5.5 Support Personnel
Dr Joe Ryan
Dr Joe Ryan (the project supervisor) is available to support the project.
University of Ballarat Staff
University staff can also provide assistance to the project team.
1.3.6 Current and planned operating sites
Inkjet & Toner is a small Ballarat business and is currently operated from home. The physical
site of installation has been visited by the project team, it was briefly assessed and it has been
assumed that it will be suitable (have adequate space, cooling/ventilation etc.) for the proposed
new system to operate on the same site.
Version: 4 Date: 05/05/2006 13
1.4 Current Business Processes
A flowchart depicting the current business and system processes can be found in Appendix 1 of
this document.
1.5 Constraints
The following list outlines the constraints placed on the project team in completing this project:
Budget
The project is a student project and the project team does not have an official budget.
All project work will be completed as inexpensively as possible and make use of open
source/freeware where available. See budget contained within Section 6.
Time
The project team are all full-time students and as such have limited time to perform
project activities due to requirements from other University units, work commitments
and other individual commitments. An approximate commitment of 260 hours per
project team member is expected (1040 hours in total).
People
This project is made up of four university students and is limited to those members in
performing the work to complete the project. The team cannot hire outside assistance
and is limited to the use of Support Personnel outlined in Section 1.3.5.5.
Equipment
The equipment available for use by the project team (hardware and software) is limited
to the equipment provided by the University of Ballarat and group members‟ own
personal equipment. It may be possible for members to borrow any extra equipment
required from external parties however availability cannot be guaranteed in these cases.
Note: Refer to project feasibility in Section 3.6 and Section 3.7 for further constraints. Also refer
to Section 4 regarding specific project requirements.
Version: 4 Date: 05/05/2006 14
1.6 Evaluating Project Success
This section outlines the procedures to be used in evaluating whether the project objectives
(contained within Section 1.3.2) have been met once the system is completed and operational.
Site traffic meter
A site traffic meter or counter will be used in evaluating how much traffic is being
generated by the website. Cookies can be used to determine how many new customers
are visiting the site. This will test the success of Objective 1 „Attract new customers‟.
Customer surveys
Customer surveys will be used to determine if Objective 3 „Improve service for existing
customers‟ is being met. This may include a simple questionnaire about whether the
customers feel the services have improved by providing an additional contact channel.
Customer surveys will also provide insight into whether customers are using the website
or sticking to existing business procedures (Objective 1 „Provide a web presence).
Customer can also be asked whether the website provides useful information in regard to
purchasing products (Objective 5 „Provide information‟).
Reviewing geographical location of clientele
Geographical information can be recorded about where each product is delivered. This
will show whether the website has generated sales that would have otherwise not
occurred due to geographical restrictions (Objective 2 „Attract new customers‟), and if the
business has received addition exposure (Objective 1 „Provide a web presence‟).
Client feedback
Mr. Neil Patterson can provide feedback as to whether the website has improved
business efficiency and thus satisfied Objective 4 „Improve efficiency‟. Neil can also
provide insight into whether the website has increased exposure and resulted in the
attraction of new customers through looking at variations on sales (Objective 1 and
Objective 2).
Version: 4 Date: 05/05/2006 15
1.7 Document Structure
The SRS is organised into the following major areas:
Section 1 – Project Overview
This section provides an overview of this document and what it is designed to provide. It
covers the current business processes and the current system and the system to be
developed. Including any constraints affecting the success of the product. Success test
requirements or acceptance criteria are also defined.
Section 2 – Definitions
This section provides a list of all abbreviations and acronyms used in the document.
Section 3 – General Description
This section states the required functions that relate to the main objectives of the
product. Users of the system are identified and assessed. High level user interfacing is
demonstrated by use case scenarios. The project feasibility is also discussed.
Section 4 – Specific Requirements
Section 4 lay out all the specific requirements that that relate to the project. Including
database, operating, quality, software and training requirements. Other requirements are
also covered in depth such as the specific functional requirement, the external interfacing
requirements and the performance requirements of the system.
Section 5 – Copyright
This section simply covers any issues of copyright.
Section 6 – Project Budget
This section details a project budget, this is a student project and is not seen to incur any
substantial costs to the client. This budgeting section is a requirement of the CP783
Project Unit. Figures displayed are estimated and fictitious, they should not be taken
literally.
Appendices
The appendices contain any images or diagrams that were not found to be suitable in the
body of the text. It also may include imported data.
Version: 4 Date: 05/05/2006 16
References
This section contains a listing of all documents, policies, templates, processes, and other
sources of information referenced in this SRS document.
Version: 4 Date: 05/05/2006 17
2.0 Definitions and Acronyms
Acronyms
CSS Cascading Style Sheets
ER Diagram Entity Relationship Diagram
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protocol
ISP Internet Service Provider
ITIOW Inkjet & Toner Information and Ordering Website
JSP Java Server Pages
MTA Mail Transfer Agent
PDA Personal Digital Assistant
RAM Random Access Memory
SMTP Simple Mail Transfer Protocol
SMS Short Message Service
SQL Structured Query Language
SSL Secure Sockets Layer
TCP/IP Transmission Control Protocol/Internet Protocol
WAP Wireless Application Protocol
Definitions
Client Inkjet & Toner Cartridge Recycling
User Also „end user‟. Will be any person using the product for its designed purpose.
Version: 4 Date: 05/05/2006 18
3.0 General Description
3.1 Product Functions
The ITIOW will execute many specific functions primarily designed to keep the product as
maintenance free as possible. It will also aid in the growth for the business by increasing the
customer base and sales through alternative means to the currently provided forms of contact.
The interface will need to be as user friendly as possible to accommodate for the wide range of
end users that will be accessing it. As a broad overview, the main functions of the product are
specified below:
Display products (U1)
The site should demonstrate the products (and their specifications if appropriate)
supplied by the business. The site will reference a back-end database to provide
these details. This helps build on the web presence objective of the site, showing
customers all the different services and products that are offered by the business.
This function is directly linked to Objective 1 in Section 1.3.2.
Provide ordering facilities (U2)
Once signed up to the website, customers will be able order products directly from the
site. Ordering is in place to help improve service for the existing users. This function is
directly linked to Objective 2 in Section 1.3.2.
Administrator section (U3, U5)
An administration function will be required to allow the client to update and maintain
the site as required, which includes the processing of supplier price lists. This should
be very user friendly and as automated as possible.
Provide FAQ section (U4)
The site will provide an FAQ/Help section to assist in customer service and efficiency,
and will mainly be designed for end-users to assist them with any problems that they
may encounter with the site, and also to obtain answers to commonly asked
questions regarding compatibility, original vs. compatible cartridges etc. This will also
need to be updateable by the administrator as required. This function is directly linked
Version: 4 Date: 05/05/2006 19
to Objective 5 in Section 1.3.2.
Sign up/Log in (U6)*
Provide a sign up function to the site. This will be a verification check for customers
that wish to order over the Internet. The sign up function will help to improve efficiency
and service for new and existing customers – one of the main objectives for the site,
see Objective 4 in Section 1.3.2.
Provide Contact Information (U7)
The website will provide contact information for those customers wishing to contact
the business directly. This function is directly linked to Objective 5 in Section 1.3.2.
Search (U8)
There will be a search function incorporated in the site for users who know exactly
what they require. This function will be ideal for assisting efficiency for certain users,
such as return customers locating products in which they already know the details.
This function is directly linked to Objective 3 in Section 1.3.2.
*Note: The references in brackets next to the function headings (user requirements) map to the
Traceability Matrix contained in Appendix 4.
Version: 4 Date: 05/05/2006 20
3.2 User Characteristics
It is expected that the system will comprise of two main user groups:
Employees of the Business
At this stage, Inkjet & Toner Cartridge Recycling consists of only one member of staff,
Mr Neil Patterson (the owner of the business), who will be responsible for regular
maintenance and updating of the system.
Customers of the Business (both existing and potential new customers)
It is expected that the customers will come from a wide range of backgrounds, with
the majority expected to be business professionals from the local area. It has also
been noted that not all of the intended users will be highly technology literate. Some
may be home users that are new to the internet, and some may be consistent internet
„explorers‟ that may know their around a computer fluently. It is important that both
types are catered for by the system.
3.3 Assumptions and Dependencies
It is assumed that with a detailed user manual the client will be able to sufficiently
maintain the site without requiring help from external parties.
It is also assumed at this point in time that the site will be hosted on a server provided
by the client. This server will be setup by the project team specifically for the website.
The project team (as students) will be able to access all software required for
development of the product.
Testing will be performed using „dummy data‟ for users and genuine supplier product
lists for products and pricing.
Version: 4 Date: 05/05/2006 21
3.4 Product Outlook
3.4.1 User Interfacing
3.4.1.1 Use Cases
This section demonstrates certain functions of the designed solution using high level use case
diagrams (or examples). Each use case is spelt out and the corresponding use case diagram
found in Appendix 2.
Use Case 1 – Administrator login
Actors: Administrator, the client (Neil) logging in to perform administration tasks.
Procedure:
1. The client will type a designated administration extension onto the end of the site‟s
URL. This is done mainly to keep administration transparent to the end users (and
also acts as a form of „security by obscurity‟ by not making the administration URL
available to general visitors).
2. The client is taken to an „Administrator Login‟ page. Here the username and
password are entered. If that user is not listed as an administrator then they are
denied access. Otherwise they are logged into the administration section of the
site.
3. Once logged in the client will have access to perform a range of tasks, such as
validation of members and updating of pricing and product listings.
Exceptions:
1. If the administrator provides the wrong password, they will be re-prompted. 3
invalid attempts will lock account for 5 minutes.
Database requirements:
„Administrator‟ table will be accessed. „CustomerID‟ and „Password‟ will be read.
Note: Use Case 1 is a prerequisite of some other cases. This is noted at the
beginning of their individual procedure section.
Version: 4 Date: 05/05/2006 22
Use Case 2 – Pricing updates
Actors: Administrator.
Procedure:
1. Use Case 1 must be performed prior to this task.
2. Once the client has logged in as an administrator they will be presented with a list
of options to choose from. Included in this list will be the pricing update option.
3. Once the pricing updates option is selected the user will be prompted to select
and upload a relevant pricing file. This will be a MS Excel file supplied from the
wholesaler.
4. After the system has the location of the pricing document it can automatically
update the product database.
Exceptions:
1. If the wrong type of file is selected the user will be prompted to select another file.
Database requirements:
„Product‟ and „ProductSuppliers‟ tables will be accessed and modified.
Version: 4 Date: 05/05/2006 23
Use Case 3 – Membership validation
Actors: Administrator.
Procedure:
1. Prerequisites for this task are Use Case 1 and Use Case 4.
2. After the administrator logon the user is presented with an option to „Validate
Memberships‟.
3. Once this has been selected the user will be shown a list of memberships that are
pending approval. These will have a brief summary and can be selected on an
individual basis.
4. The user can then review the applications and contact the users with further
enquiries, or approve the applications as desired.
5. There will be a „Create Membership‟ button at the end of the validation screen that
will capture all of the information from the completed application form into a new
membership, and then email the new membership details to the requestor.
Exceptions:
1. If administrator validates the wrong user, they will be an option to invalidate or
suspend their account
Database requirements:
„Customer‟ table will be accessed and modified.
Version: 4 Date: 05/05/2006 24
Use Case 4 – Membership application
Actors: End users.
Procedure:
1. When a user first visits the site they will have no membership to the site. If they
access a section of the site that requires a logon, they will be redirected to the
membership login page (there will be an option here to go to the new „Membership
Application‟ page). This page can also be accessed from the homepage.
2. Once at the „Membership Application‟ page the user will be required to enter their
details. These will have a preliminary validation by the system (e.g. checks that
mandatory fields are completed, phone numbers are of appropriate length). The
user can submit their application.
3. Use Case 3 applies here.
Exceptions:
1. If user enters the wrong information, they will be able to modify it once they have
been validated.
2. If user cannot (or will not) provide required information, they are denied application
and given the option to contact Neil by email.
Database requirements:
„Customer‟ table will be accessed and modified.
Version: 4 Date: 05/05/2006 25
Use Case 5 – Member logon
Actors: End users.
Procedure:
1. The prerequisite for this operation is Use Case 3
2. When an end user visits the site they will be required to login before they may
place an order.
3. If a user goes to any section of the site that requires authentication they will be
redirected to the „Member Login‟ page.
4. The user then enters their username and password. The system verifies this
information and if correct takes them back to either the homepage or the page that
they were at previously.
Exceptions:
1. If user types in wrong password they are denied access. On the third wrong
attempt they are redirected to a lost password screen.
Database requirements:
„Customer‟ table will be accessed. „CustomerID‟ and „Password‟ will be read.
Version: 4 Date: 05/05/2006 26
Use Case 6 – Order placement
Actors: End users.
Procedure:
1. The prerequisite for this operation is Use Case 5.
2. Once the user has been logged in to the system they may place an order.
3. To place an order the user will need to browse through the product listings and
select the products that they wish to order. This will be done by using an „Add to
Cart‟ button.
4. Once the user has finished creating their order they will go to the „My Cart‟ section.
Here they can verify what they have ordered and remove items or return to the
product listings to add more items as required. At this stage, the user will also
have the option to add any additional comments regarding their order.
5. The user then selects a „Submit Order‟ button. This will send the user a
confirmation email and also sends the order via email to Inkjet & Toner.
Exceptions:
1. If the user submits accidentally submits an order, they will be given the option to
cancel it by email within 24 hours.
Database requirements:
„Customer‟ will be accessed and read. „Order‟, „OrderItems‟ will be modified.
Version: 4 Date: 05/05/2006 27
Use Case 7 – Browse products
Actors: End users.
Procedure:
1. Users will be able to navigate to products by clicking the product categories on the
sites navigation bar.
2. Users also have the option of using the “Search” box, which will be located in the
top right hand corner of the screen.
Exceptions:
None.
Database requirements:
„Product‟, „ProductCategory‟ and Category‟, will be accessed and read.
Use Case 8 – Access help and contact information
Actors: End users.
Procedure:
1. An end user will be able to access help easily from anywhere within the site by
clicking the “Help” button.
2. Users can find the business contact information using the header graphics of the
site.
3. Users can also get further details by clicking the “Contact Us” link located on all
pages.
Exceptions:
None.
Database requirements:
None. (Contact information will be provided on a static page at this point in the
project, but this may change in the future)
Version: 4 Date: 05/05/2006 28
3.4.1.2 Activity Diagrams
The activity diagrams show the basic flow of the main processes. They can be located in
Appendix 3 of this document.
3.4.2 Memory Constraints
The system will not require large amounts of memory or processing power, the minimum
requirements are demonstrated in Section 4.3. In the event that user traffic is outweighing the
ITIOW server, then upgrades (memory, processor or bandwidth) may be required.
The database will be able to store an indefinite amount of product lines, with the exact amount
to be determined by pricing documents provided by suppliers. If there are seven parts to each
product line, including a description and (if available) images, this may equate to approximately
500KB of database space per entry. It is expected that there will be somewhere in the vicinity of
3000 entries held in the database at any one time. This would mean that the minimum storage
required for the database will be around 1500MB (3000 entries x 500KB each).
In addition to product lines, the member list will need to be stored as well. The current customer
base of I&T is estimated by the client at around 300 people and businesses. The member
database will need to allow for twice this amount at the minimum. Each member entry would be
expected to require around 50KB of storage space. Thus the member database will require
around 15MB of storage space as a minimum requirement.
Site visits and validation requests are expected to be closely inter-twined and according to the
current customer base, it is expected that once the site is operational that there will be around
3-5 visits per hour. The server minimum requirements are detailed in Section 4.3.2 and should
allow for approximately 10 users to be logged onto and surfing the site simultaneously with no
noticeable impacts on loading times.
3.4.3 Operations
Once the ITIOW is up and running on its own, the server will require very little software
maintenance. The main maintenance requirements will be the regular updating of the product
pricing and a backup of the membership database and this will be via the administrator login. An
Version: 4 Date: 05/05/2006 29
installation disc will be provided to the client allowing the whole site to be able to be completely
reinstalled (therefore the site itself will not need to be backed up).
In the case a complete reinstall is required then the most recent price listing, alongside the
latest membership database, will also need to be reloaded into the system. These processes
will be made as automated as possible, to the point where they will simply be a click and select
operation requiring minimal technical knowledge or user intervention.
3.4.4 Adaptation Requirements
Currently it is not expected that the site will require further adaptation from what is to be
produced as a result of this project. If adaptation is required then it is foreseen to be minimal,
and may entail things such as format changes and general look and feel options to do with the
user interfaces. As far as the client has specified, the site will not need to be installed on
multiple servers or in multiple geographical locations. Adaptation will be constantly revised in
future development stages to ensure that the site can keep up with a very dynamic industry and
does not become outdated in a short period of time.
3.5 User Base
The user base is expected to be quite large and very diverse. It is expected that the user base
will start off small, with mainly local community users that are first notified of the site by physical
advertising. This will most likely come from current customers of the business. For further
expansion, consideration may be given to having the site listed on search engines such as
http://www.google.com. It is expected that the geographical base of users will grow over time,
but will be limited to Australia.
Version: 4 Date: 05/05/2006 30
3.6 General Design Constraints
There are certain other generalised constraints that may affect the project and the way it is
developed. These constraints are listed below:
Scope
The scope is bound by what the client wants and requires. Scope also applies to what
the project team can actually manage or what is physically possible. This can relate to
resource restraints or skills that are needed to perform certain tasks.
Time
Time will be the major driving constraint for this project. The time frame is set to one (1)
university year. This contains a single teaching period (6 months) for initial
documentation and planning and a second period for development, creation, testing and
implementation.
Cost
Cost will be a limiting factor. As this is a student project completed without funding, the
costs relating to the project will be kept to a minimum (see also Section 1.5).
Objectives
The project is bound to the objectives set out in Section 1.3.2 of this document.
Anything outside of these objectives will generally not be considered due to time and
resource constraints, however, allowances can be made as the project team sees fit.
External Constraints
The system is restricted to the supplied format of stock sheets and must be capable of
reading this format. Stock sheets will vary between suppliers and may change over
time. The stock sheets are created and distributed by the supplier and their format
cannot be controlled. A sample supplier stock sheet in contained within Appendix 5.
Version: 4 Date: 05/05/2006 31
3.7 Project Feasibility
Economic
The project is economically feasible, with the expected costs heavily outweighed by the
expected gains that will result from the project. The only costs in implementing the
project will be obtaining the required hardware and purchase of a domain name for the
business. As a result of this, the only ongoing costs will be renewal of the domain name
and replacement/repair of hardware on the rare occasions that it malfunctions. The
project budget is contained within Section 6.
Operational
The project is operationally feasible. It will help to make the business more efficient. The
pricing and ordering functions aim to reduce the workload encountered by the client,
and the client has stated that they will be able to use the product directly for customer
prices rather than manually searching price lists. This demonstrates that the project will
provide many benefits for the business.
Technical
The project will be designed in planning to be technically feasible during the
development and creation stages. All sections of the ITIOW will be thoroughly
investigated before being submitted into the project plans.
Legal / Political
No legal or political issues are likely to affect the feasibility of the website. The only
foreseeable issue would be if the project team was to sell the product or a modified
version of it commercially, with a view to make profit. In this situation the University of
Ballarat may be entitled to royalties on the product (see Section 5.0 for more details).
The probability of this situation arising is minimal as the ITIOW is specifically designed
for only one purpose.
At this stage further clarification is required as to whether there are any issues with
using company logos and pictures of their products can be used within the site.
Version: 4 Date: 05/05/2006 32
4.0 Specific Requirements
4.1 External Interface Requirements
4.1.1 User Interfaces
All users will require a standard graphical web-browser (including, but not limited to Mozilla
Firefox or Microsoft Internet Explorer) to interact with the developed solution. As at the date of
release of this document, it is intended that this will be the only way to interact with the system,
although consideration will be given to ensuring that the system will be expandable in the future
to support emerging technologies such as mobile phone/SMS orders, and WAP browsing (e.g.
from PDA‟s).
Version: 4 Date: 05/05/2006 33
4.1.2 Interface Storyboards
4.1.2.1 Template Interface
All pages within the site are to follow the following standard template.
Search Box
Inkjet & Toner Logo
Contact Information
Current Site Location (Relative path from homepage)
Product Name
Navigation
Product Details
Copyright Information, Privacy Policy
The following provides details on each component contained within the template:
Inkjet & Toner Logo
The Inkjet and Toner logo will be placed in the top left hand corner of all pages.
Search Box
A search box will always be accessible from any page, in the top right hand corner.
Version: 4 Date: 05/05/2006 34
Contact Information
Contact information will be made available as part of each page‟s header. This will be
part of the page graphics and contain the phone number and address etc.
Navigation
Navigation will be provided for each top level product category, and when a certain
category is selected, it will be expanded.
Current Site Location
This page element will use breadcrumb navigation, this is very simple to use and will
provide the user with additional navigation information and show the relative path from
the homepage.
Page Contents
The majority of the page will be filled with specific page content.
Copyright Information/Privacy Policy
The page footer will provide a link to the site privacy policy and contact information. This
is a necessity for all eCommerce sites in order to provide trust.
Version: 4 Date: 05/05/2006 35
4.1.2.3 – Product Page
The following diagram shows the basic layout of how products will be listed:
Search Box
Inkjet & Toner Logo
Contact Information
Current Site Location (Relative path from homepage)
Product Name
Product Image
Navigation
Description
Availability/
Purchase
Price Estimated
Link
Delivery Time
Copyright Information, Privacy Policy
The following provides details on each component contained within the template (see Section
4.1.2.1 for further explanation):
Product Name
The name of the product will be listed here.
Product Image
An image will be included. However this is not mandatory as not all product will have an
image.
Version: 4 Date: 05/05/2006 36
Price
The price of the product will be included in Australian dollars (including GST).
Availability/Estimate Delivery Time
The current availability status and estimate delivery time will be included.
Description
A description of the product will be provided to the user. This may provide a link to further
information in regard to the product or the supplier.
Version: 4 Date: 05/05/2006 37
4.1.2.4 – Order Page
The following diagram shows the basic layout of orders will presented:
Search Box
Inkjet & Toner Logo
Contact Information
Current Site Location (Relative path from homepage)
Order Heading
Billing Address Delivery Address
Navigation
Order Contents
Subtotal
Freight
GST
Additional Comments (from Customer) Total Amount Payable
Confirm Order
Copyright Information, Privacy Policy
The following provides details on each component contained within the template (see Section
4.1.2.1 for further explanation):
Order Heading
An order heading will be included.
Billing Address and Delivery Address
The customer billing and delivery addresses will be displayed for verification purposes.
Version: 4 Date: 05/05/2006 38
Order Contents
A list of products the client wishes to purchase will be displayed.
Additional Comments
Any additional comments the customer wished to be added can be entered here.
Subtotal Freight GST and Total Amount Payable
A calculation of the total amount will be displayed. This includes a sub-total, freight, GST.
Confirm Order
The user will be given an opportunity to review the order before pressing the confirm
button.
Version: 4 Date: 05/05/2006 39
4.1.2.5 – Search Page
The following diagram shows the basic layout the search results:
Search Box
Inkjet & Toner Logo
Contact Information
Current Site Location (Relative path from homepage)
Search Results Heading
Navigation
Description Price Available
Search Navigation (Previous/Current/Next Result Pages)
Copyright Information, Privacy Policy
The following provides details on each component contained within the template (see Section
4.1.2.1 for further explanation):
Search Results Heading
The page will clearly be labels “Search Results” and include the query string.
Description, Price, Available
A short description of all product matches will be listed, along with the price and
availability.
Version: 4 Date: 05/05/2006 40
4.1.2.6 – Administrative Page
The following diagram shows the basic layout how the administrative page will be presented:
Search Box
Inkjet & Toner Logo
Contact Information
Current Site Location (Relative path from homepage)
Admin. Heading
Manage
Customer
Accounts Link
Pending Customer Applications
Navigation Load Stock
Sheets
Manually Load
Prices
Sales and Stock Information
Add Specials
Copyright Information, Privacy Policy
The following provides details on each component contained within the template (see Section
4.1.2.1 for further explanation):
Admin Heading
The administrator section will be clearly labelled.
Pending Customer Applications
Any pending customer applications will be listed.
Sales and Stock Information
Sales data and stock information will be provided here, such as the number of sales last
Version: 4 Date: 05/05/2006 41
week etc.
Manage Customer Accounts
A button/link will be provided to manage customer accounts. This will either go to another
page or load a pop-up window.
Load Stock Sheets
An option will be provided to load a stock sheet. This will either go to another page or
load a pop-up window.
Manually Load Prices
An option will be given to manually load prices and override the automatic updates. This
will either go to another page or load a pop-up window.
Add Specials
The administrator will be able to add specials by clicking this link/button. This will go to a
new page or load a pop-up window.
Version: 4 Date: 05/05/2006 42
4.1.3 Hardware Interfaces
As this solution is exclusively web-based, no direct connections to hardware interfaces will be
required (note that indirect connections to devices such as printers may be possible, however
are the responsibility of the web browser and underlying Operating System and fall outside the
scope of this system).
4.1.4 Software Interfaces
The following Software Interfaces are required by the system:
Web Browser – Interprets the HTML and enables the web pages to be displayed on the
end-user‟s computer system.
HTML – Responsible for providing necessary text and formatting/layout commands for
the web pages to be displayed in the user‟s browser,
JSP – Server-side scripting language that will interface between HTML and MySQL (i.e.
by retrieving products from database, and then producing the necessary HTML code
dynamically)
MySQL – A relational database management system that will be used to store details of
available product lines, prices, quantities available etc. This will interface with JSP.
Version: 4 Date: 05/05/2006 43
4.1.5 Communications Protocols
The principal communications protocols required for the correct operation of this system include
the following:
TCP/IP – to facilitate communication between the client web-browser and the server, and
also for communication with other servers (note that no attempts will be made to support
IPv6 in the delivered solution due to the slow take-up and limited support offered by most
Australian ISPs).
HTTP – For transfer of generated HTML data and HTML get/post requests across the
TCP/IP connection.
SQL – To enable the backend MySQL database to be queried and updated as required.
SMTP – For sending of order-related emails to MTAs (Mail Transfer Agents) for delivery
to the intended recipient.
SSL – To facilitate the encryption of secure and/or confidential data between the end-
user‟s PC and the application server using public-key cryptography.
Version: 4 Date: 05/05/2006 44
4.1.6 Site Map
4.1.6.1 Customer Interface
The diagram below shows the site map proposed solution.
New
Printers Used
Accessories
Home/Specials Products
Inkjet
New Consumables Laser
Fax
Inkjet
Reman. Consumables Laser
Media Fax
Other*
Services Repairs
Contact Info.
Privacy Policy
Search
Sitemap
Order Page Login Page
Note: The red arrow indicates that if the customer is not already logged in, they will be
forwarded to the login page before accessing the order page.
Version: 4 Date: 05/05/2006 45
4.1.6.2 Administrative Interface
The following diagram shows the administrative interface, which will be separated from the main
customer interface.
Admin. Home Add Specials
Load Stock Sheets
Login Page
Manually Load Prices
Manage Cust. Accounts
Note: The red arrow indicates that if the administrator is not already logged in, they will be
forwarded to the login page before accessing any administrative functions.
Version: 4 Date: 05/05/2006 46
4.2 Database Requirements
4.2.1 Entity-Relationship Diagram
An Entity-Relationship (ER) diagram for the database component of the solution is shown
below. Please note that this diagram should be interpreted with regards to the explanatory notes
listed in Section 3.2.2.
Customer
Order
PK CustomerID
PK OrderID OrderItems
FirstName
LastName places an / is placed by SubmitDate consists of / make up an PK,FK1 ProductID
DeliveryAddress ShipDate PK,FK2 OrderID
BillingAddress PaymentMethod
Phone PaymentRef Quantity
Email PaymentDate
Password FK1 CustomerID
Validated contain / make up
Product
has an / belongs to ProductSuppliers PK ProductID
PK,FK1 ProductID is supplied by / supply OEMCode
PK,FK2 SupplierID Description
OnHand
Price
Address Estimate
PK AddressID URLLink
Address1 is supplied by / supply
Address2 is assigned a / consists of
City
State
Postcode ProductCategory
Country Suppliers
PK,FK1 ProductID
PK SupplierID PK,FK2 CategoryID
ContactName
Phone
Email
Administrators belongs to / consists of
PK Username
Category
Password
PK CategoryID
CategoryName
Version: 4 Date: 05/05/2006 47
4.2.2 Explanatory Notes to the Entity-Relationship Diagram
The following notes are designed to assist in the interpretation of the Entity-Relationship
Diagram in Section 3.2.1:
Attributes shown in bold are mandatory (i.e. not optional).
Attributes shown with an underline make up the primary key for the entity in which they are
shown.
The dashed line between Customer and Order signifies that there is a non-identifying
relationship between these two entities (the primary key of the Customer entity is included
in the Order entity, however does not form part of the primary key for an Order). The same
reasoning applies for the relationship between Customer and Address.
Version: 4 Date: 05/05/2006 48
4.2.3 Database Schema
The intended schema for the database component of the solution can be seen below. Primary
Keys are indicated in bold and Foreign Keys in italics:
TABLE NAME: FIELD: TYPE: DESCRIPTION:
CUSTOMER CustomerID Number Primary Key
FirstName Text(30)
LastName Text(30)
DeliveryAddress Number References ADDRESS(AddressID)
BillingAddress Number References ADDRESS(AddressID)
Phone Text(15)
Email Text(50)
Password Password
Validated Boolean
ORDER OrderID Number Primary Key
CustomerID Number References CUSTOMER(CustomerID)
SubmitDate Date/Time
ShipDate Date/Time
PaymentDate Date/Time
PaymentMethod Text(10)
PaymentRef Text(10)
ORDERITEMS OrderID Number References ORDER(OrderID)
ProductID Number References PRODUCT(ProductID)
Quantity Number
PRODUCT ProductID Number Primary Key
OEMCode Text(15)
Description Text(300)
OnHand Number
Price Number
Estimate Boolean
URLLink Text(150)
PRODUCTCATEGORY CategoryID Number References CATEGORY(CategoryID)
ProductID Number References PRODUCT(ProductID)
CATEGORY CategoryID Number Primary Key
Version: 4 Date: 05/05/2006 49
TABLE NAME: FIELD: TYPE: DESCRIPTION:
CategoryName Text(40)
PRODUCTSUPPLIERS SupplierID Number Primary Key
ProductID Number References PRODUCT(ProductID)
SUPPLIERS SupplierID Number Primary Key
ContactName Text(50)
Phone Text(15)
Email Text(50)
ADDRESS AddressID Number Primary Key
Address1 Text(30)
Address2 Text(30)
City Text(20)
State Text(3)
Postcode Number
Country Text(20)
ADMINISTRATORS Username Text(12) Primary Key
Password Password
Version: 4 Date: 05/05/2006 50
4.3 Operating Requirements
4.3.1 Client-side
The following requirements are the recommended minimum requirements for client users of the
system. Satisfactory performance cannot be guaranteed if these specifications are not met:
Pentium II/Celeron (or equivalent) running an Operating System capable of
communicating using TCP/IP.
64MB RAM
24-bit colour display, operating at a recommended resolution of 1024x768 (with a
minimum resolution of 800x600).
Mouse (or other pointing device)
Keyboard
Any recent web-browser capable of supporting common web standards (e.g. CSS).
4.3.2 Server-side
The following requirements are the recommended minimum requirements for the server
component of the system. Satisfactory performance cannot be guaranteed if these
specifications are not met:
Apache Web-Server (Version 1.3 or above) configured for Tomcat/JSP support.
MySQL (Version 4 or higher).
Pentium III 1000Mhz (or equivalent)
512MB RAM
4.4 Software Requirements
4.4.1 Client-side
Web Browser (including but not limited to: Mozilla Firefox, Microsoft Internet Explorer,
Safari, Netscape and Opera)
Version: 4 Date: 05/05/2006 51
4.4.2 Server-side
Apache Web-Server (Version 1.3 or above) configured for Tomcat/JSP support and
MySQL support (Version 4 or higher).
Version: 4 Date: 05/05/2006 52
4.5 Specific Functional Requirements
The following table provides a description of all priorities used in the functional requirements
listed. Each requirement is also numbered sequentially in order or priority from most important
to least important.
PRIORITY: DESCRIPTION:
Critical This function must be included and forms the core of the product. The
completed project cannot succeed without it. Critical functions must be given
preferential treatment over all other functionality.
Very High This function must be included, although it doesn‟t form the core of the
system. Very high priority functions are to be included after implementing
critical functions.
High It is highly recommended that a function of high priority be included, however
failure to do so won‟t cripple the project. Failure to include a high priority
function may stop certain objectives from being met.
Medium These functions are to be included in the project, but will be included only if
all higher priority functions have first been implemented. Failure to include a
medium priority function will not affect satisfaction of project objectives.
Low Low priority functions will only be completed if all other functions have been
completed and are not necessary for project success. Low priority functions
include „bells and whistles‟ that do not directly link to solving project
objectives.
4.5.1 Automatically load stocks (S1)
Description The system must be able to read and load stock sheets into the
database. The user is not required to enter products one by one.
Criticality It is important that stock sheets be added automatically as there is too
much information to add manually and the information is expected to
change regularly. This will help with the improving efficiency – see
Objective 1 in Section 1.3.2.
Technical issues Creating an algorithm to read the excel files, especially if the stock
sheets change.
Cost and Schedule This project is not expecting any costs in this area. The schedule to
complete this function and to have it fully operational is mid-November
2006 (refer to the SPMP for further scheduling details).
Risks Stock sheets could change and cause the system to incorrectly read
them. Stock sheets may not be available.
Dependencies None
Priority 6 (High)
Version: 4 Date: 05/05/2006 53
4.5.2 Verify users (S2)
Description The system must be capable if identifying and verifying users.
Criticality It is very important that users be verified so that they can place orders
without having to re-enter account information each time.
Technical issues Include processes for changing password, or getting new password if
forgotten. Password encryption in database or „over the wire‟.
Cost and Schedule This project is not expecting any costs in this area. The schedule to
complete this function and to have it fully operational is mid-November
2006 (refer to the SPMP for further scheduling details).
Risks Database could fail and no users can access site. Fake orders may
enter the system.
Dependencies Requires up to date user database – 3.5.12
Priority 3 (Very high)
4.5.3 Allow users to sign up (S3)
Description New users must be able to sign up.
Criticality The system must allow new customers to sign up in order to adequately
attract new customers (see Objective 2 in Section 1.3.2).
Technical issues The system must verify that users really exist before adding to the
system. Provide a system where users can also update their details.
Cost and Schedule This project is not expecting any costs in this area. The schedule to
complete this function and to have it fully operational is mid-November
2006 (refer to the SPMP for further scheduling details).
Risks Fake users may enter the system. People may „spam‟ the system with
fake users.
Dependencies None
Priority 4 (Very high)
4.5.4 Provide product listings (S4)
Description The website will provide a listing of products to the user in which they
can browse.
Criticality It is crucial that customers be able to browse the products offered.
Technical issues Products must be categorised in some way.
Cost and Schedule This project is not expecting any costs in this area. The schedule to
complete this function and to have it fully operational is mid-November
2006 (refer to the SPMP for further scheduling details).
Risks Products are entered into wrong category and cannot be found. Product
database fails and no products are listed.
Dependencies Requires up to date product listings – 3.5.1
Priority 1 (Critical)
Version: 4 Date: 05/05/2006 54
4.5.5 Provide search functions (S5)
Description The website will contain search functionality for finding products (by
product number for example) and other services offered.
Criticality It‟s important that customers be able to quickly find what they are after in
order to retain their business. Customers will not want to manually soft
through pages of products.
Technical issues Products must be categorised in some way.
Cost and Schedule This project is not expecting any costs in this area. The schedule to
complete this function and to have it fully operational is mid-November
2006 (refer to the SPMP for further scheduling details).
Risks Products are entered into wrong category and cannot be found. Product
database fails and no products are listed.
Dependencies Requires up to date product listings – 3.5.1
Priority 5 (High)
4.5.6 Process orders (S6, S11)
Description The system will be capable of processing user orders.
Criticality The system must be able to process customer orders. The payment
system will make use of current offline business processes (which is
currently preferred by client), but may provide online payment
functionality (which can be disabled).
Technical issues Implementing security certificates to guarantee security
Cost and Schedule This project is not expecting any costs in this area. The schedule to
complete this function and to have it fully operational is mid-November
2006 (refer to the SPMP for further scheduling details).
Risks The order may not go through even though customer submitted it.
System may not calculate order correctly
Dependencies Requires up to date product listings – 3.5.1, verification of users – 3.5.2,
security – 3.5.8.
Priority 8 (High)
4.5.7 Provide help functions (S7)
Description The website must contain easily accessible help on all pages.
Criticality Customers must be able to easily access help at all times.
Technical issues The help system must be always kept up to date.
Cost and Schedule This project is not expecting any costs in this area. The schedule to
complete this function and to have it fully operational is mid-November
2006 (refer to the SPMP for further scheduling details).
Risks Help not providing the answer to customer problem.
Dependencies None
Priority 11 (Medium)
Version: 4 Date: 05/05/2006 55
4.5.8 Security (S8)
Description The system will be made secure from outside attacks and unauthorised
access.
Criticality As this product is going to be accessible on the Internet, it is important
that it has security in place to make it harder for hackers, viruses,
„malware‟ etc. to access or damage important areas of the website.
Technical issues If someone (or something) is able to alter the prices of the products, site
design etc. then this is likely to be detrimental to the image of the
business. Security needs to be put in lace without adversely affecting
the sites useability too much.
Cost and Schedule This project is not expecting any costs in this area. The schedule to
complete this function and to have it fully operational is mid-November
2006 (refer to the SPMP for further scheduling details).
Risks Unauthorised access or modification to the website.
Dependencies None
Priority 9 (High)
4.5.9 Allow for manual updates (S9)
Description The website will enable database entries from automatic stock sheets to
be manually overridden. Specials will also be manually entered.
Criticality It is important for any automatic prices added to the database to be
manually overridden to compete with competitors or offer specials, etc.
Technical issues The automatic prices are not to be overridden. The manual prices are to
be substituted instead. The system must provide administration of all
manual updates (to prevent them getting lost and affecting future
automatic updates).
Cost and Schedule This project is not expecting any costs in this area. The schedule to
complete this function and to have it fully operational is mid-November
2006 (refer to the SPMP for further scheduling details).
Risks The manual updates could potentially stay in the system and overwrite
all new automatically updates.
Dependencies None
Priority 7 (High)
Version: 4 Date: 05/05/2006 56
4.5.10 Provide contact information (S10)
Description The system will make business contact information available on all
website pages.
Criticality Contact information must appear on the website so customers can
contact the business. It is very important that this information is kept up
to date.
Technical issues Keeping contact information up to date.
Cost and Schedule This project is not expecting any costs in this area. The schedule to
complete this function and to have it fully operational is mid-November
2006 (refer to the SPMP for further scheduling details).
Risks Providing wrong contact information, or contact information going out of
date.
Dependencies None
Priority 2 (Critical)
4.5.11 Administration system (S12)
Description The system will provide a web based administrative interface for
managing user‟s accounts and updating the website.
Criticality An administration system must be in place to manually add new
customers, delete old customers, suspend customers with outstanding
accounts etc.
Technical issues When a customer is added using the administrative system, the first
time they log in they should be prompted for a new password rather than
the default one.
Cost and Schedule This project is not expecting any costs in this area. The schedule to
complete this function and to have it fully operational is mid-November
2006 (refer to the SPMP for further scheduling details).
Risks Accidentally deleting a customer.
Dependencies None
Priority 10 (High)
*Note: The references in brackets next to the functional requirements map to the Traceability
Matrix contained in Appendix 4.
Version: 4 Date: 05/05/2006 57
4.6 Performance Requirements
4.6.1 Reliability
The system must be reliable and not crash or have any down time apart from that outlined in
Section 3.6.2 below. To facilitate this, a regular database backup (not requiring user
intervention) will be scheduled during low-use periods to ensure that the risk of losing customer
or order details is mitigated. In addition to this, time-stamped database transaction logs, and
system level logs (generated by the web and database daemons) will be maintained. These will
be used to assist in the identification of any performance issues or unexpected actions that
could occur during normal use of the system.
4.6.2 Availability
The system must aim to be available at all times (24 hours a day, 7 days a week, 365 days a
year), with a Service Level Availability of 98% or higher. This allows for approximately 174 hours
of downtime each year, which may include ISP disruptions and scheduled preventative
maintenance. Wherever possible, any such maintenance should be conducted during off-peak
(low traffic) times to minimise disruption to potential users, and notification of planned
maintenance given before it occurs.
4.6.3 System Level Security
The underlying Operating System should be secured against external security attacks through
the use of the following components:
A firewall allowing connections only to specified and required ports, and also employing
rate-limiting technology to drop packets from hosts that are attempting to breach security
on the system (e.g. making an unreasonably large number of connections in a short
period of time, such as 5 SSH connections in less than a minute). This should assist in
deterring hackers, and provides a level of protection against Denial of Service attacks.
Anti-virus scanning that is scheduled to update virus definitions, and to perform full-
system scans at regular intervals. This anti-virus scanning will also apply to incoming and
outgoing email relayed through the system.
Version: 4 Date: 05/05/2006 58
4.6.4 Application Level Security
Only allow authenticated users should have access to specified functions. For example, users
can only place orders if they have an account that has been activated by the application
administrator, and a user account should be locked if too many attempts are made to logon to
the account.
4.6.5 Maintainability
There are three main categories of maintenance that may be required to ensure that the system
remains operational in an optimal state: Corrective, Preventative and Perfective. Any
maintenance required must be conducted in accordance with the availability provisions outlined
in Section 3.6.2. From an end-user perspective, the system must have few, if any, manual
maintenance requirements, and any action required on the part of the intended users should not
be time-consuming to perform.
Corrective maintenance on the system will be performed as and when necessary, within a
timeframe relative to the issue that requires correcting. If the issue is a critical one requiring the
system to be taken offline, such as one causing the system to be unavailable to end-users, or
orders being unable to be processed, then the issue should be resolved at the earliest possible
opportunity. Other less severe cases may include an inconsistency in formatting across pages,
or the tuning of SQL queries to provide more accurate results. In these cases (where there is a
risk that disruptions may occur), the maintenance should be scheduled to occur during a low-
traffic period.
Preventative maintenance which may cause brief impacts to service availability or result in slow
response - such as the downloading and installation of upgrades, updates and patches, log
file/security analysis, database dumps/backups, or temporary file cleanups - should occur
overnight in low-traffic periods, and any failures or abnormalities encountered notified to the
system administrators via email.
Perfective maintenance will normally refer to small problems, such as typographical errors or
minor page formatting issues. In most cases, these can be corrected on-the-fly and should not
necessitate any system downtime. If the changes to be made are not consistent with these
Version: 4 Date: 05/05/2006 59
examples, then they should be considered to be corrective maintenance.
4.6.6 Speed
The web server must not become slow or unresponsive during peak periods, and be equipped
with enough processing power to deal with all requests in a timely manner. Should the database
daemon experience an usually high load, then the web site should display a message to users
advising of expected slow-response or unavailability, instead of attempting to process the
request and failing.
Version: 4 Date: 05/05/2006 60
4.7 Quality Requirements
Usability
A user with minimal computer skills must be able to easily find what they are looking for
through clicking the mouse button on specific links or through a search function. The
administrator must be able to log on and update the website easily. This includes
updating the database through Excel files and uploading pictures onto the web page. The
website should also be atheistically pleasing to the user, and have a professional look
about it by having the same format, colour and structure throughout the website.
Efficiency
As the products change regularly this web site must not increase the workload to the
business through updating and maintenance. While some time is expected to be spent
on updating it must be automated as much due to the fact there are thousands of
products and it would be to time consuming to add them in one by one. The system is
expected to be able to help with existing business processes by providing other
alternatives with ordering and promoting products that are on special.
Adaptability
The system should be able to adapt to product changes. For example, if a new type of
printer is created, it should be able to be easily added to the site and if the business does
not want to sell a product that a supplier provides it should be able to be removed from
the web page. If the format of supplier stock sheets change, the system should cope with
this without too much difficulty.
Extensibility
The system will be created in such a way that it will be easily extensible, if a new supplier
comes along the products from the supplier must be able to be added to the website with
minimal effort or if an existing supplier changes the format of their Excel files the system
should adapt to these changes
Version: 4 Date: 05/05/2006 61
4.8 Training Requirements
The client will require sufficient training in regard to the ITIOW to allow them to self maintain the
site into the future. The training will make use of the following items:
Fully functional, production version of the ITIOW.
Backup CD to be provided with the product.
ITIOW specific web server.
ITIOW instruction and user manual.
The training will involve showing the client how to successfully perform the following tasks:
Upload product information.
Find relevant instructions in the user manual.
Restore the website and the latest member and product lists in the event of a critical
server failure.
Setup the server in a different physical location.
How to search the site for product information.
Approving new members to the site.
Resetting member passwords.
How to order with the site (So that end users may be taught).
Version: 4 Date: 05/05/2006 62
5.0 Copyright Issues
Copyright is not likely to be an issue for this project. The intellectual property can generally be
considered jointly owned by the client (Neil Patterson) and the project team. However, if the
product created (or a variant of it) goes commercial, the University of Ballarat may enforce its
part ownership of the intellectual property and be entitled to a share of any earnings made as a
result.
Version: 4 Date: 05/05/2006 63
6.0 Project Budget
Note: This project is a student project, and as such there will not be any substantial costs
associated with it. However, this costing section has been included as part of the „CP783
Project 1‟ requirements.
6.1 Initial Fixed Costs (Start up cost)
Hardware
Server x1 600
Router x1 150
Keyboard/mouse switch x1 each 100
Total hardware costs 850
Software
Linux server (all software used will be freeware/open source) 0
Total software costs 0
Total costs $850
6.2 Project Staffing Costs
Chris Allely Jeremy Egan Michael Ellery Dan Meade Total
Pate per hour 60 40 40 40 180
Expected hours per week 10 10 10 10 40
Expected duration (weeks) 26 26 26 26 104
Total hours 260 260 260 260 1040
Total cost $15,600 $10,400 $10,400 $10,400 $46,800
6.3 Annual Reoccurring Costs
Hardware
Server maintenance 100
Upgraded ADSL speed ($10 per month) 60
Domain name costs 40
Total costs $200
Version: 4 Date: 05/05/2006 64
6.4 Expected Financial Benefits
Assumptions:
The system will attract an extra 10 customer per month, who each spends $50 per month
on average.
The system will keep retain 2 customers to per month that would have otherwise left, who
each spend $50 per month on average.
The ease of use of the new system will mean that the existing customer base of 50
customers will now spend an extra $10 per month.
New customers per month 10
Retained customers 2 12
Expected purchases per month 50
Total benefit from new and retained customers $600
Existing customer base 100
Expected additional purchases 10
Total benefit from existing customers $1,000
Total gain in revenue $1,600
Therefore, the yearly increase is revenue can be expected to be $19,200.
Version: 4 Date: 05/05/2006 65
6.5 NPV Analysis
Assumptions:
This calculation only considers the cash flow, and therefore excludes depreciation
The NPV analysis shows a 5 year period, but the expected gains and losses may
continue for a greater period.
Year 0 1 2 3 4 5
Increase in revenue 19200 19200 19200 19200 19200 19200
less Expenses
Initial fixed costs 850
Project staffing costs 46800
Server maintenance 100 100 100 100 100 100
Upgraded ADSL 120 120 120 120 120 120
Domain name costs 25 25 25 25 25 25
Total costs 47895 245 245 245 245 245
Net cash flow ($28,695) $18,955 $18,955 $18,955 $18,955 $18,955
Payback Period: 1.5
Net Present Value* $39,326 *Discount Rate: 10%
Version: 4 Date: 05/05/2006 66
Appendices
Appendix 1: Business Flowchart
New
Used
Printers Accessories
Remanufactured
Refill
Inkjet Compatible
An order is created after the
customer selects the good
they require
This is the end of the scope
of the system to be
Original developed
Website Consumables Create Order Good in Stock? Y Deliver Goods Receive Payment
Remanufactured
Refill
N
Order Goods
Laser Compatible From Supplier
Original
Fax Rolls Compatable
Media
Repair
Version: 4 Date: 05/05/2006 67
Appendix 2: Use Case Model
Information and Ordering
System
Administrate
Website (Logon)
«uses»
Update Website
Validate
Memberships
Administrator «uses»
Apply for
Membership
Member Logon
«uses»
End User (Customer)
Place Order
Browse Products
Help and contact
information
Version: 4 Date: 05/05/2006 68
Appendix 3: Activity Diagrams
Pricing updates
This activity diagram demonstrates the process required for the Administrator to update the
pricing on the website.
Administrator
Login
Unverified
Verification
Verified
Select pricing Browse for pricing
update file
Return
confirmation of Submit pricing file
pricing update
Version: 4 Date: 05/05/2006 69
Customer ordering
This activity diagram shows the process for a customer to place an order.
User Login
Unverified
Verification
Verified
Select product Confirm shopping
from listing cart
Return
confirmation of Submit order
pricing update
User logoff
Version: 4 Date: 05/05/2006 70
Appendix 4: Traceability Matrix
ID: User Requirements: Forward Tractability:
U1 Users must able to browse products S4, S5
U2 Users shall be able to submit orders (and buy) S6, S11
U3 Admin user must be able to update prices S1, S9
U4 Users must be able to access hints and information S7
U5 Admin users should have access to an S2, S9, S7, S12
administrative interface
U6 Users must log in or be able to sign up S2, S3, S8
U7 Users must be able to access contact information S10
U8 The site must provide a search function S5
ID: Functional Requirements: Backward Tractability:
S1 The system automatically loads stock sheets U3
S2 The system verifies users (username/password) U6, U5
S3 The system must allow users to sign up U6
S4 The system must provide a listing of all products U1
S5 The system will provide a search function U1, U8
S6 The system must accept and process orders U2
S7 The system provides a FAQ section (which is U4, U5
editable by administrator)
S8 The system must be secure U6
S9 The system allows automated prices to be U5, U3
overridden
S10 The system must provide up to date contact U7
information
S11 System must provide a payment system (to be U2
clarified at this stage)
S12 The system must provide administration over U5
customer accounts
Note: This Tractability Matrix is referred to in Sections 3.1 and Section 4.5.
Version: 4 Date: 05/05/2006 71
Appendix 5: Supplier Stock Sheet
Version: 4 Date: 05/05/2006 72
References
The references below were used in the creation of this document:
Texts
Neilsen, J. (2000). Designing Web Usability. United States of America: New Riders Publishing.
Standards
IEEE 830-1998: IEEE Recommended Practice for Software Requirements Specifications.
Internet Material
Huscher, B. (2000). Database Design and Modeling Fundamentals – Table Design. Retrieved
May 5, 2006 from http://www.sqlteam.com/item.asp?itemID=122.
Version: 4 Date: 05/05/2006 73
Client Sign-Off
I, as proprietor and sole owner of Inkjet & Toner Cartridge Recycling, verify that the content of
this here Software Requirements Specifications document consistently characterises the
requirements specified for the Inkjet & Toner Ordering & Information Website (ITIOW). By
signing this statement I accept the product in full delivered by Team E of the University of
Ballarat, as so outlined and agreed upon in this document.
This document has been officially signed and witnessed on the _____ day of __________ in the
year 2006.
Signed:
NAME POSITION HELD SIGNATURE
Neil Patterson Client/Project Sponsor
Chris Allely Project Manager
Jeremy Egan Team Member
Michael Ellery Team Member
Daniel Meade Team Member
Witnessed by:
NAME POSITION HELD SIGNATURE
Joe Ryan Supervisor
Version: 4 Date: 05/05/2006 74