ITEC150 2017 - Session 2: CRM150 Software Requirements Specification

This Software Requirements Specification (SRS) document outlines the requirements for the CRM150 web-based system designed for the Australian Business Company (ABC). The report begins with an introduction, including the purpose, conventions, and intended audience. It then delves into the business domain, describing the client organization and the problems they face with their outdated "Sales Management" software. The project introduction defines the scope, assumptions, and constraints, along with the system operating environment and testing approach. The document details the software development methodology, functional and non-functional requirements, and system functional decomposition, including sub-systems for people details management, sales order processing, and reports/enquiries. It also includes a candidate system class diagram and discusses system database modeling and data design, and system user interface. Appendices include a glossary and references. The document is a comprehensive guide for stakeholders, including senior managers, business analysts, and developers, to ensure a clear understanding of the CRM150 system's specifications.

ITEC150 2017 – Session 2 –– Software Requirements Specification, SRS for Project CRM150
Software Requirements
Specification, SRS
For
The Australian Business Company, ABC
CRM150
“A Customer Relationship Management System”
Copyright © 2017 by group 1 - Modification and/or distribution of this document is not permitted without permission Page i

ITEC150 2017 – Session 2 –– Software Requirements Specification, SRS for Project CRM150
Table of Contents
1. SRS DOCUMENT INTRODUCTION ...................................................................................................... 1
1.1 P URPOSE OF D OCUMENT ........................................................................................................................... 1
1.2 DOCUMENT C ONVENTIONS ....................................................................................................................... 2
1.3 I NTENDED AUDIENCE AND R EADING SUGGESTIONS .................................................................................. 2
2. BUSINESS DOMAIN ................................................................................................................................. 3
2.1 T HE C LIENT ORGANIZATION ..................................................................................................................... 3
2.2 THE CLIENT ORGANIZATION PROBLEM ..................................................................................................... 3
2.3 P ROPOSED BUSINESS SOLUTION ................................................................................................................ 3
3. PROJECT INTRODUCTION ................................................................................................................... 5
3.1 P ROJECT S COPE ......................................................................................................................................... 5
3.2 P ROJECT A SSUMPTIONS AND C ONSTRAINTS .............................................................................................. 5
3.3 SYSTEM OPERATING ENVIRONMENT ......................................................................................................... 6
3.4 P ROJECT T ESTING APPROACH ................................................................................................................... 6
4. OUR SOFTWARE DEVELOPMENT METHODOLOGY .................................................................... 8
5. SYSTEM FUNCTIONAL AND NON-FUNCTIONAL REQUIREMENTS ......................................... 9
5.1 S YSTEM FUNCTIONAL REQUIREMENTS ..................................................................................................... 9
5.2 S YSTEM N ON- FUNCTIONAL REQUIREMENTS ............................................................................................. 9
6. SYSTEM FUNCTIONAL DECOMPOSITION ..................................................................................... 11
6.1 FIRST S UB -SYSTEM (EXAMPLE , PEOPLE D ETAILS MANAGEMENT ) .......................................................... 14
6.2 S ECOND S UB -SYSTEM (EXAMPLE , SALES O RDER PROCESSING ) .............................................................. 17
6.3 T HIRD SUB - SYSTEM ( EXAMPLE , R EPORTS AND E NQUIRIES ) .................................................................... 17
6.4 AND SO ON… .................................................................................... ERROR ! BOOKMARK NOT DEFINED .
7. CANDIDATE SYSTEM CLASS DIAGRAM ........................................................................................ 26
8. System Database Modelling and Data Design
9. System User Inter Face
APPENDIX A: GLOSSARY...............................................................................................................................31
APPENDIX B: REFERENCES..........................................................................................................................2
Copyright © 2017 by group 1 - Modification and/or distribution of this document is not permitted without permission Page ii

ITEC150 2017 – Session 2 –– Software Requirements Specification, SRS for Project CRM150
Revision History
Name Date Reason for Changes Version
Team members 27 July 2017 First Version 0.1
Hoang Linh Nguyen 28 July 2017 Add Introduction 0.2
Shamima Akter and 28 July 2017 Add Project Introduction 0.3
Imran
Muhammad Umar 28 July 2017 Add Business Domain 0.4
Haral
Adel Aloqauli 28 July 2017 Add Software Development Methodology 0.5
Zheng Wu 28 July 2017 Add Business Problems 0.6
Hoang Linh Nguyen 28 July 2017 General review, combine and edit sections 0.7
Adel Aloqauli 28 July 2017 Add use case diagram for the development 0.8
methodology
Hoang Linh Nguyen 28 July 2017 Add 4.2 Testability (missing due to mistake) 0.9
and References
Hoang Linh Nguyen 09/09/2017 Improve Introduction 1.0
Shamima Akter and 09/09/2017 Improve Project Introduction 1.1
Imran
Muhammad Umar 09/09/2017 Improve Business Domain 1.2
Haral
Adel Aloqauli 09/09/2017 Improve Software Development Methodology 1.3
Zheng Wu 09/09/2017 Improve Business Problems 1.4
Hoang Linh Nguyen 09/09/2017 Add System Functional Decomposition 1.5
Diagram
Imran 09/09/2017 Add first Sub-system (Administration) 1.6
Adel Aloqauli 09/09/2017 Add second Sub-system (Sales Order) 1.7
Zheng Wu 09/09/2017 Add third Sub-system (Report and Enquiries) 1.8
Copyright © 2017 by group 1 - Modification and/or distribution of this document is not permitted without permission Page iii

ITEC150 2017 – Session 2 –– Software Requirements Specification, SRS for Project CRM150
Hoang Linh Nguyen 09/09/2017 Add Fourth Sub-system (Marketing) 1.9
Hoang Linh Nguyen 09/09/2017 Update Appendix A and Appendix B 2.0
Imran 09/09/2017 Add Candidate System Class Diagram 2.1
Muhammad Umar 27/09/2017 Improve Second Sub-system 2.2
Haral
Shamima Akter 27/09/2017 Improve Third Sub-system 2.3
Zheng Wu 27/09/2017 Add section 8 2.4
Imran 27/09/2017 Improve all the use case diagrams and section 2.5
class diagram (section 7)
Shamima Akter 28/09/2017 Improve Project Scope 2.6
Hoang Linh Nguyen 28/09/2017 Add Section 9: User Interface 2.7
Hoang Linh Nguyen 28/09/2017 Final review 2.8
Copyright © 2017 by group 1 - Modification and/or distribution of this document is not permitted without permission Page iv

ITEC150 2017 – Session 2 –– Software Requirements Specification, SRS for Project CRM150
1. SRS Document Introduction
The introduction of the Software Requirement Specification (SRS) provides an overview of the
entire SRS including the purpose of document, document invention, intended audience and reading
suggestions [1]. The aim of this document is to fully define the complete Customer Relationship
Management 150 (CRM150) system and its functions which were built based on the requirements
required by stakeholders and their needs. Nevertheless, this document will present a number of
business issues that the client – the Australia Business Company (ABC) is facing caused by the
outdated software Sales Manager. The new CRM150 web-based system will be a perfect
replacement for the old system and also a powerful tool for the ABC to manage their relationship
with customers and to improve the business process.
The Unified Modeling Language (UML) will be used for visualizing, specifying, constructing
and documenting information about software-intensive system along with a number of use cases
to deliver a clear overview of the main system functional and non-functional requirements. The
use cases will mainly be used to describe the interactions between users and the system. All of the
collected requirements will also be listed fully in this document.
1.1 Purpose of Document
This Software Requirements Specification document specifically introduce and outline the
requirements for the CRM150 web-based system to the ABC senior managers and the executives
[1]. One of the main purpose of this document is providing a specific and objective view of the
CRM150 system, giving a good explanation of its complete functions. In addition, the main
concentration will be the requirements required by stakeholders and their needs of changes during
the testing process. This means that all the requirements made by stakeholders will be
documented and analyzed carefully and furthermore, any changing requirement during the testing
process will also be responded immediately. All of the requirements made by stakeholders will be
gathered, analyzed and listed fully in this document.
This SRS document contains seven main sections; each section is provided along with
its sub-sections.
Section 1, SRS Document Introduction
Section 2, Business Domain
Section 3, Project Introduction
Section 4, Our Software Development Methodology
Section 5, System Functional and Non-Functional
Requirements Section 6, System Functional Decomposition
Section 7, Candidate System Class Diagram
As a result, this document would be used as the central point of discussion among all the
interested stakeholders during the different phases of the system development lifecycle.
Copyright © 2017 by group 1 - Modification and/or distribution of this document is not permitted without permission Page 1

ITEC150 2017 – Session 2 –– Software Requirements Specification, SRS for Project CRM150
1.2 Document Conventions
1. Business term’s first letters are Capitalised.
2. Abbreviations are CAPITALISED.
3. Important statements are bolded.
4. Text in italic needs to be confirmed or replaced.
5. The meaning of “must”, “should”, “must not”, “should not”, “may not”, “required”,
and “recommended” are defined as in RFC2119.
6. Text font used in Times New Roman with the size of 12.
7. Text font used for titles is Times New Roman - Heading 1 style (size 18) and subtitles
is Times New Roman - Heading 2 style (size14).
1.3 Intended Audience and Reading Suggestions
This document is intended for all the system stakeholders, it should be read and reviewed by:
1. The senior managers and executives of our client
2. The business analysts who are involved in the project
3. User and client representatives working in the subject area
4. Other reviewers who are experts in the subject area
Also, this document is to be reviewed and/or used by:
1. The project Team as a standard domain vocabulary for communication
2. System architect to create Solution Architecture
3. System analysts and designers for system design and modelling
4. Developers to implement the system
1. Testers for software inspections and testing against its principle and agreed-
on specifications
5. Client and end users for the continual testing and feedbacks
6. Documentation writers to create user’s and technical documents
Copyright © 2017 by group 1 - Modification and/or distribution of this document is not permitted without permission Page 2

ITEC150 2017 – Session 2 –– Software Requirements Specification, SRS for Project CRM150
2. Business Domain
Customer relationship management refers to the use of practices or strategies that are used by
companies for analysing the customer engagements [2]. The main involvement of this process is
the analysis of the various sales outlets like websites, stores or emails.
CRM helps in analysing the customer interactions and helps in predicting the sales growth. In
addition, it also helps in knowing the post engagement required in front of the target audience.
2.1 The Client Organization
The Australian Business Company, called ABC, is a noteworthy provider of electronic gadgets
and a vast supplier of specialized administrations built up in 1980 in Sydney, Australia. The
central mission of the organization is showcasing and offering diverse electronic gadgets as a
merchant/retailer for some global organizations, for example, Apple, Samsung, IBM, Sony, Group
and Xerox.
2.2 The Client Organization Problem
According the present situation, the company is using an old software application called “Sales
Management” which has raised problems due to it outdating that result to current system unable
to process insufficiently and functioning satisfactorily. This system could be isolation, non-
extensibility, and lacks openness. It will be hard for company to maintain the system due to the
expensive cost and the time for understanding internal workings of the system. Moreover, the
situation could be serious when the system has tis vulnerabilities that can result to security issues.
(1997, B. Wu, D. Lawless, J. Bisbal, J. Grimson, V. Wade, D. O'Sullivan, R. Richardson)
2.3 Proposed Business Solution
Although “Sales Management” unable working satisfactorily, it still can be improved by provide
a web-based interface through our service called “Customer Relationship and Business Processes
Manager” that convenient for people who are not familiar with software to use.
Copyright © 2017 by group 1 - Modification and/or distribution of this document is not permitted without permission Page 3

ITEC150 2017 – Session 2 –– Software Requirements Specification, SRS for Project CRM150
3. Project Introduction
The Australian Business company which is a major supplier of electronic devices and a large
provider of technical services established back in 1980 in Sydney, Australia. Currently, the ABC is
using an old computer system. However, according to the present requirements and demands of
customer, the old system is no longer suitable. Additionally, in that case of updating this system, it
will be very expensive and unrealistic. According to that it has been decided by senior management
of ABC to create a new system. The project will only include the stages of system analysis and
design including modelling, database design and user interface.
3.1 Project Scope
The project includes a new software system analysis, design, modelling, database design and user
interface design. The need for new business requirements is mainly due to ABC's problem as the
existing system is no longer functioning adequately due to its age and insufficient and
unsatisfactory capabilities. In addition, the project includes an high-level description of a
potential solution to help the fundraising organisation to achieve their major objectives
3.1.1 Project Inclusive Aspects (Within the Project Scope)
The main aspects included in this project are the statement of the organization problem,
business drivers and technical constraints, functional Requirements, use case and
system class diagrams, non-functional Requirements, database design and model [3].
3.1.2 Project Exclusive Aspects (Out of the Project Scope)
The following aspects are out of the project scope:
1. Programming and coding
2. Unit testing
3. System environment setup
4. System hosting and deployment facilities
5. System configuration
6. System backup and restore facility
7. End users training
8. System maintenance and upgrade
3.2 Project Assumptions and Constraints
The main assumptions include licensing and general requirements for the business to use CRM
successfully. In addition, a remote sever set up which will provide sufficient security protection as
user’s personal information will be stored in the database. Moreover, staff will need to be
adequately trained in advance to easily transition from the old system increasing efficiency.
Furthermore, budget will be provided and managed by the client and storage of files will be
facilitated to fit government legislations of 6 years.
The various assumptions and constraints that needs adherence are included here. The software
must be accessible via a cloud based facility providing security and 24/7 access. In addition,
transactions and records must be stored to adhere to government legislations for a minimum of 6
years. The software must have compatibility features to enable user access from various platforms
and operating systems [3]. In addition, security of payments and information, like credit cards,
PayPal or bank transfer must be facilitated. Moreover, scalability to the client’s requirements and
Service Oriented Architecture Approach must be implemented.
Copyright © 2017 by group 1 - Modification and/or distribution of this document is not permitted without permission Page 4

ITEC150 2017 – Session 2 –– Software Requirements Specification, SRS for Project CRM150
3.3 System Operating Environment
The system must be design as web-based set of applications that must be hosted in a cloud
facility for 24/7 availability. The reason for this is the flexibility and scalability cloud
computing provides. The Cloud computing technology helps to neglect the necessity for a physical
hardware by creating visual architectures. This helps the companies to work at a much faster rate.
1. Cloud computing technologies help to integrate software into the cloud where it can be used and accessed
from anywhere.
2. Almost all of the browsers allow access to the cloud architecture.
3. Reliability is another feature as access will always be guaranteed.
4. Security is also another benefit of this application.
5. According to the client, scalability is achieved.
3.4 Project Testing Approach
The development process will require the participation of the client company and their business
professionals at all time for monitoring the development progress of the project. Feedbacks and approvals
must be collected regularly at every stage of the development process changes will be made
accordingly before moving on to the next stage. The main focus of the system testing is to make sure
that the end result meets the business and user requirements. Additionally, the stakeholders will gain
their confidence by receiving a quality product. All of the components of the system will be evaluated
to ensure that they can work at the optimum level of working [3]. This process also includes the
reviewing of the process and this will be repeated continually until the system is successfully
implemented. Furthermore, customer's reviews, opinion, complain or additional requirements will be
documented to review for the next stages of project implementation.
Copyright © 2017 by group 1 - Modification and/or distribution of this document is not permitted without permission Page 5

ITEC150 2017 – Session 2 –– Software Requirements Specification, SRS for Project CRM150
4. Our Software Development Methodology
The software development methodology used for this project management is the use of waterfall methodology.
This method is used making a sequential flow of the required steps to be integrated in the development phase of
the project [4]. These method resemblances a waterfall where the top layer is followed by underlying bottom
layer.
Copyright © 2017 by group 1 - Modification and/or distribution of this document is not permitted without permission Page 6

ITEC150 2017 – Session 2 –– Software Requirements Specification, SRS for Project CRM150
5. System Functional and Non-functional Requirements
The introduction of the Software Requirement Specification (SRS) provides an overview of the
entire SRS including the purpose of document, document invention, intended audience and reading
suggestions [1]. In addition, the SRS report will be used to know about the main intentions of the
stakeholders as well as the software output.
5.1 System Functional Requirements
The first requirement of includes the presence of administrators to add new customer details or
delete them from the database. In addition, the administrators will also be able to create new orders
or delete them as well as track the order completion. Moreover, the administrator will also be able
to create system backup as well as edit sales report. The analysis report will also be made by the
administrators.
5.2 System Non-functional Requirements
The system is supposed to be in operations for 24 hours in a day and be responsive to the
authorities. In addition, the data will also be saved at regular intervals.
5.2.1 System Quality Attributes
The quality attributes are used to determine the attributes of the project management methods. This
includes the security, availability, maintainability and reliability [3].
5.2.2 Business Rules
The administrator should have full details of the user while a user is getting registered to the
system. Sales report will be generated weekly, quarterly or yearly [3]. The administrator should
have full access to sales reports.
5.2.3 Government legislations
While designing software plan, consideration of all the lawful necessities (that have been set by the
administration specialists to keep away from any business struggle or potentially wrongdoing) has
to be considered [4]. Software should retain the transaction of 5 years for company record and
Government audit. The transactions must contain all the records of receiving and sending
payments.
Copyright © 2017 by group 1 - Modification and/or distribution of this document is not permitted without permission Page 7

ITEC150 2017 – Session 2 –– Software Requirements Specification, SRS for Project CRM150
5.2.4 Other Non-functional Requirements
It is necessary to keep backup of all data files and system in a separate directory / drive. In
addition, frequent auto-save of information to prevent loss of network connection and crashes of
browser and unexpected crash of the system is required [4]. Moreover, power supply should be
always on to assure the system is running all the time with no interruption.
6. System Functional Decomposition
Copyright © 2017 by group 1 - Modification and/or distribution of this document is not permitted without permission Page 8