REQUIREMETS AALYSIS FOR SBS SYSTEM AD STUDY REVIEW PROCESS ITERATIO DURIG REQUIREMETS PHASE
ALGHAMDI, HAA MUSAFER H
REQUIREMENTS ANALYSIS FOR SBS SYSTEM AND STUDY REVIEW
PROCESS ITERATION DURING REQUIREMENTS PHASE
ALGHAMDI, HANAN MUSAFER H
A project report submitted in partial fulfillment of
the requirements for the award of the degree of
MSc. (Computer Science – Real Time Software Engineering)
Centre for Advanced Software Engineering
Faculty of Computer Science and Information System
Universiti Teknologi Malaysia
v
ABSTRACT
This paper represented the experience gained and discussed the works done under
the title “Requirements Analysis For SBS System And Study Review Process Iteration
During Requirements Phase” by the author during her Industrial Attachment 2 Period,
from 13th October 2008 to 13th March 2009, at HeiTech Padu, Malaysia. The purpose of
this paper is to analyze requirements for Shared Banking Services system and study
reviews process that can be applied in requirement phase in order to get quality
requirements document with reduced errors. The SBS system is aimed to provide the
banking services, of one selected bank, through post office in order to give the customer
other alternative way to perform his or her banking services. There were some studies is
carried out to understand how the reviews process is important in requirement phase and
to show how to make the reviews process more effective by iterate it during the
development of SRS document. The required methodology to achieved objectives of this
paper began from initiation and planning, an analysis of Shared Banking Services system,
study about best practices in requirements engineering process and study requirements
review process. Finally, documentation of the output was performed. The development
team of SBS system used ADVISE methodology which is based in HeiTech Padu process
development. The deliverables of analyzing SBS system are Software Requirement
Specification (SRS), Requirement Traceability Matrix and User Manual documents. A
workflow is introduced to show how the reviews process can be iterated during
vi
ABSTRAK
Kajian ini membincangkan pengalaman dan hasil kerja yang telah dijalankan oleh
penulis di bawah tajuk “Analisis Keperluan Untuk Sistem SBS Dan Kajian Pengulasan
Proses Pengulangan Semula Semasa Fasa Keperluan” semasa Latihan Industri 2 beliau
yang bermula pada 13 Oktober 2008 hingga 13 Mac 2009 di HeiTech Padu, Malaysia.
Kajian ini bertujuan untuk menganalisis keperluan-keperluan untuk sistem Perkhidmatan
Perkongsian Perbankan dan untuk mengkaji proses pengulasan yang boleh diaplikasikan
ke dalam fasa keperluan untuk memperoleh dokumen keperluan yang berkualiti beserta
jumlah kesalahan minima. Sistem SBS mensasarkan untuk membekalkan perkhidmatan
perbankan, daripada satu bank terpilih, melalui pejabat pos dalam memberikan pelanggan
alternatif lain untuk menyempurnakan perkhidmatan perbankannya. Beberapa kajian
telah dijalankan untuk memahami kepentingan proses pengulasan dalam fasa keperluan
dan untuk mempamerkan bagaimana untuk menjadikan proses ini lebih efektif dengan
mengulangkan ia semula semasa pembangunan dokumen SRS. Metodologi yang
diperlukan untuk mencapai objektif-objektif kajian ini bergerak dari permulaan dan
perancangan, analisis sistem Perkhidmatan Perkongsian Perbankan, kajian tentang
praktis-praktis terbaik dalam proses kejuruteraan keperluan dan juga kajian keperluan
proses pengulasan. Akhirnya, proses dokumentasi hasil telah dijalankan. Kumpulan
pembangunan sistem SBS telah menggunakan metodologi ADVISE yang berdasarkan
proses pembangunan HeiTech Padu. Hasul daripada analisis sistem SBS adalah Perisian
Spesifikasi Keperluan (SRS), Matriks Keperluan Kebolehan Menjejaki dan dokumen
vii
TABLE OF COTETS
CHAPTER TITLE PAGE
DECLARATIO ... ii
DEDICATIO ... iii
ACKOWLEDGEMET ... iv
ABSTRACT ... v
ABSTRAK ... vi
TABLE OF COTETS ... vii
LIST OF TABLES ... xi
LIST OF FIGURES ... xii
LIST OF ACROYMS ... xiv
LIST OF APPEDICES ... xv
1 ITRODUCTIO ... 1
1.1 Company Background ... 1
1.2 Project Background ... 4
2 PROJECT OBJECTIVES / SCOPES ... 6
2.1 Introduction ... 6
2.2 Project Objectives ... 6
2.3 Project Scopes ... 7
viii
3 LITERATURE STUDY ... 9
3.1 Introduction ... 9
3.2 Systems Development Life Cycle Overview ... 9
3.2.1 Rational Unified Process... 11
3.3 System Requirements Analysis Overview ... 13
3.3.1 System Requirements Analysis Activities ... 14
3.3.1.1 Requirements Elicitation ... 15
3.3.1.2 Requirements Analysis ... 16
3.3.1.3 Requirements Specification ... 17
3.3.1.4 Requirements Validation ... 18
3.3.1.5 Requirements Managements ... 19
3.3.2 Classification of Requirements ... 20
3.3.2.1 Functional Requirements ... 20
3.3.2.2 Non Functional Requirements ... 21
3.3.3 System Requirements Analysis Modeling ... 21
3.3.3.1 Use Case Model ... 21
3.3.3.2 Sequence Diagram ... 27
3.3.3.3 Collaboration Diagram ... 29
3.3.3.4 State Transition Diagram ... 30
3.3.4 Requirements Traceability ... 32
3.4 Requirements Review Process ... 33
3.4.1 The Importance of Requirements Review ... 33
3.4.2 SRS Errors ... 34
3.4.3 SRS Characteristics ... 36
3.4.4 Recommended Review Techniques Can Integrate in Requirements Analysis Phase ... 38
3.4.5 Study On Related Existing Approach ... 41
3.4.6 Requirements Review for HeiTech Padu Berhad ... 43
ix
4 PROJECT METHODOLOGY ... 50
4.1 Introduction ... 50
4.2 Project Methodology ... 50
4.2.1 Phase 1: Project Initiation and Planning ... 52
4.2.2 Phase 2: Analysis ... 52
4.2.2.1 Literature Review ... 52
4.2.2.2 Analyze SBS System ... 53
4.2.2.3 Survey ... 53
4.2.3 Phase 3: Develop Documentation ... 54
4.2.4 Technique ... 54
4.2.4.1 Research And Reading ... 54
4.2.4.2 Object-Oriented Approach ... 55
4.2.4.3 UML Notation ... 56
4.2.5 Tool ... 57
4.3 SBS System Development Methodology... 58
4.3.1 SBS Requirements Process ... 59
4.3.2 Standard and Guideline ... 60
5 PROJECT DISCUSSIO ... 62
5.1 Introduction ... 62
5.2 Part One: SBS System ... 62
5.2.1 SBS System Architecture ... 63
5.2.2 External Interface Requirements ... 67
5.2.3 SBS System Use Case Diagram ... 68
5.2.3.1 User and Their Role ... 70
5.2.3.2 Sign In Use Case ... 70
5.2.3.3 Open Account Use Case ... 71
5.2.3.4 Make Cash Deposit/Payment Use Case ... 71
5.2.3.5 Withdraw Money Use Case ... 72
x
5.2.3.7 Maintain Passbook Use Case... 73
5.2.3.8 Remit Money Use Case ... 74
5.2.3.9 Reverse Transaction Use Case ... 74
5.2.3.10 Require Override Use Case ... 75
5.2.3.11 Manage User Profile Use Case ... 75
5.2.3.12 Perform End Of Day Use Case ... 76
5.2.3.13 Stock Control Register Use Case ... 77
5.2.3.14 View Electronic Journal And Forex Rate Use Case ... 77
5.2.4 SBS Sequence Diagram ... 79
5.2.5 User Manual ... 81
5.3 Part Two: Requirements Review Iteration Method ... 82
5.3.1 Iteration 1: Scope ... 85
5.3.2 Iteration 2: High- Level ... 86
5.3.3 Iteration 3: Detailed ... 87
5.3.4 Iteration 4: Finalized ... 88
6 COCLUSIO ... 89
6.1 Conclusion And Recommendation ... 89
REFERECES ... 91
xi
LIST OF TABLES
TABLE O. TITLE PAGE
3. 1 Inspections versus Walkthroughs 40
3.2 Comparison Between other Approaches and
HeiTech Padu Approach 45
4. 1 The Software Required To Complete The Project 57
5. 1 Transaction Subsystem Functions 64
xv
LIST OF APPEDICES
APPEDIX TITLE PAGE
A Project Plan – IA Gantt Chart 93
CHAPTER 1
ITRODUCTIO
This chapter explains about the company background, department structure and
the project background.
1.1 Company Background
HeiTech Padu is one of the largest information technology companies in Malaysia.
It provides comprehensive mission-critical solutions for public and private sectors.
HeiTech Padu was established on 1981 and it has more than 750 ICT professionals.
HeiTech Padu is an expert in transforming businesses’ manual processes to automated
systems by providing complete integrated ICT (Information and Communications
Technology) services and finally produces the effective information systems.
The main sectors that HeiTech adopts to provide ICT products and services are:
ICT infrastructure services, public sector, education, health, financial and defense and
2
The core businesses of HeiTech Padu are: manage data centre services, manage
network & communications services, systems integration services, solution &
consultancy offerings, and system integration and application development. In addition,
its vision is to be the technology-based transformational company in Malaysia and
beyond. In order to achieve this vision, HeiTech Padu has a mission which is providing
total solution, creating innovative product as well as consulting for a better world.
The industrial training was done at the Applied Research and Development
(AR&D). This department was established in October 2001. The AR&D Department’s
responsibilities and objectives consist of researching, developing, and improving HeiTech
Padu proprietary software products. Furthermore, AR&D Department aims to develop
application component which is application independent in itself. Moreover, this
department does researching the new, advanced, and emerging technology that can be
useful to HeiTech Padu software development. AR&D department undertakes a variety of
research and development activities which are: E-connect, RFID Middleware, Device
Service Server and Hybrid Client. The AR&D Structure which includes the author is
3
Figure 1.1 Applied Research and Development Department Structure
Irina Ramli
Haidayu Anuar
Edge (DSS- Device
Services Server) Haslinda M Ros
Maliki Mohamed (Head)
Halimatun Saadiah Ahmad Mohamad Yamin Ishak
Khurram Junaid Mohd Firdaus Basit
Product Development 2
Research
Suzana Bee Abd Kadir (Head)
Nor Hazilawati Awang (Head) Kamarulzaman Sali Product Development 1 Product Management
Abu Bakar Yusof (Head)
Mohd Rashidi Abd Manaf Razif Bustamal Mohamad Siss M Jamil
Premise (RFID Product)
Mohd Hairi Azly Harun
Hybrid Product Azlin Rusli
Application
Noorhafizah Mat Syned
Mohd Fadzil Mohd Jaafar Suhani Sukor Hanan Alghamdi (Practical)
4
1.2 Project Background
Organizations face many problems that slow down development of software
systems decisive to their operations and growth. Requirements process has always been
critical in the implementation of software systems. Many researchers have shown that
errors occur during requirements process are the most significant cause of software
defects, and over 40% of problems in the software development life cycle come from the
poor quality requirements [1].
Early detection and correction of requirements errors provide a high chance in
improving requirements quality and overcoming cost expending during the development
life cycle of software systems.
One of the purposes of this paper is to show that the requirements review is one
significant way to control requirements errors. This achieved by enterprise reviews or
walkthrough during developing SRS (Software Requirements Specification) in
requirements phase. In addition, this project has identified types of requirements errors
based on studying and research. After that, this project endeavored to introduce HeiTech
Padu with workflow on how to integrate review process in requirements phase. This
workflow can be applied during the development of SRS (Software Requirements
Specification) in order to produce quality requirements.
Another main purpose of this paper is to analyze requirements for Shared Banking
Service system. Shared Banking Services (SBS) is a counter-based transaction system
developed on top of a software framework name Hybrid Client for developing a
front-end, transaction based system. SBS system offers services for selected banking used to
carry out at Post office branches. SBS system consists of two main systems which are
5
Technically, SBS system works based on the components provided by Hybrid
Client and Device Service Server (DSS) in its execution. The Hybrid Client components
are used to provide common services of a transaction system, while DSS used to offer
services for device sharing and device integration. The SBS system components diagram
is depicted in figure 1.2.
Figure 1.2 SBS System Components
Shared Banking Services System
Transaction System Support/Utility
Hybrid Client
Device Service Server .Net Framework
Printer Smart
Terminal
MyKad Reader •Open Account
•Current, Saving account
•Deposit and Withdrawal
•Loan Repayment
•Credit Card
•Foreign Remittance
•Local Remittance
•Passbook Maintenance
•Inquiry
•Reversal
•User Management
•Branch Management
•Electronic Journal
•Override
•Report facility
•Start of Day processing
•Rate Downloading
•Calculator
6
CHAPTER 2
PROJECT OBJECTIVES / SCOPES
2.1 Introduction
This chapter explains about objectives and scopes of the project. It includes
project plan that has been followed during Industrial Attachment with the project.
2.2 Project Objectives
The following section shows the objectives which need to be accomplished in
order to complete the industrial attachment.
(i) To understand the current process that HeiTech Padu practice in requirements
phase.
(ii) To analyze requirements for Shared Banking Services system (SBS).
(iii) To manage and produce standard documentations which are Software
Requirement Specification (SRS), Requirement Traceability Matrix and User
Manual documents which based on requirements of Shared Banking Services
7
(iv) To study the requirements review processes during the development of SRS.
(v) To introduce the workflow in applying review process during the development
of SRS.
2.3 Project Scopes
Scope of this project is to study requirements process based on HeiTech Padu
Berhad. This study acts toward understanding of the steps for developing System
Requirements Specifications and applying requirements review in the requirements phase.
Furthermore, this project involves research at the key elements of requirements review
process that can be integrated while analyzing requirements. During research, this project
attempted to define the enterprise review process during the development of SRS.
Depending on the research and analysis, this project introduced approach to
improve practice of requirements review that can help HeiTech Padu to reduce
requirements errors. The introduced model has divided the process of the development of
SRS into phases prior to enterprise reviews or walkthrough process.
The other main aim of this project is to analyze the requirements in Shared
Banking Services system (SBS) for AR&D Department. In addition, SBS deliverables
are SRS and Requirement Traceability Matrix documents for SBS which followed
HeiTech Padu Berhad standard and guideline.
The project also focused on using the best practices of the software development
techniques and notations. The project includes the following notation and methodology:
(i) Use Unified Modeling Language (UML) notation.
8
2.4 Project Plan
91
REFERECES
1. The Standish Report (2004). Retrieved On October 20, 2008, from
http://www.standishgroup.com
2. CMS, Office of Information Services. (2005, February). Selecting A Development
Approach. Retrieved On January 12, 2009, from http://www.cms.hhs.gov
3. Section III: System Development Life Cycle. Retrieved On January 13, 2009, from
http://www.oft.state.ny.us
4. Sommerville I. and Sawyer P. (1997). Requirements Engineering – A good practice
guide. John Wiley and Sons.
5. Requirements Engineering Process. Retrieved On January 14, 2009, from
http://www.tbrc.fi/pubfilet/TBRC_500000178.pdf
6. SpringLink, Introduction to Requirements Engineering. Retrieved On January 15,
2009, from https://www.springerlink.com
7. Sommerville, Ian. (2004). Software Engineering (7th ed.). Addison Welsley.
8. Nuseibeh, B. and Easterbrook, S. Requirements Engineering: A Roadmap. Retrieved
On January 16, 2009, from http://citeseerx.ist.psu.edu
9. Rumbaugh, J. , Jacobson, I. and Booch, G. (2005). The Unified Modeling
92
10. Yousp, O. (2008). Software Specification II. Center for Advanced Software
Engineering.
11. Gursimran Walia and Jeffrey C. Carver.Using Error Abstraction and Classification
to Improve Quality of Requirements: Conclusions after Three Controlled
Experiments, Department of Computer Science and Engineering, Mississippi State
University. Retrived On Febraury 23, 2009, from
http://www.cse.msstate.edu/research/
12. IEEE. IEEE Recommended Practice for Software Requirements Specifications.
IEEE Std 830-1998. 1998
13. Eberlein A. (1997). Requirements Acquisition and Specification for
Telecommunication Services. Ph.D. Thesis. University of Wales, Swansea, UK.
Retrived On Febraury 24, 2009, from http://www2.enel.ucalgary.ca
14. Ronald J. L. (2000). Introduction to Software Engineering. Washington: CRC Press.
15. Quality standards Defect measurement manual (2000). 1.a. United Kingdom
Software Metrics Association, Metrics Practices Committee.
16. Jalote, P. (2008). A Concise Introduction to Software Engineering. London:
Springer.
17. United Kingdom Software Metrics Association. Quality Standards Defect
Measurement Manual. (2000). Retrieved On February 17, 2009, from
http://www.uksma.co.uk
18. Ralph R. Y. (2002). Recommended Requirements Gathering Practices. The Journal
of Defense Software Engineering. 9-12.
19. Rakitin S. R. Software Verification and Validation for Practitioners and Managers
93
20. Ibrahim, S. (2008). Quality and Integration. Center for Advanced Software
Engineering.
21. Gottesdiener, E. (2002). Requirements by Collaboration: Workshops for Defining
#eeds. Addison Welsley.
22. Kantorowitz, E., Guttman, A., Arzi, L. (1997). The performance of the N-fold
requirement inspection method. Requirements Engineering. 2 (3), 152-164.
Retrieved On March 4,2009, from http://www.springerlink.com
23. Li, J., Hou, L., Qin, Z., Wang, Q., and Chen, G. (2008). An Empirically–Based
Process to Improve the Practice of Requirement Review. In Wang, Q. (Ed.), Pfhal,
D. (Ed.), Raffo, D. M. (Ed.) Making Globally Distributed Software Development a
Success Story. (pp 135-146). Heidelberg: Springer Berlin.
24. Lobo L., O. and Arthur J., D. Local and Global Analysis: Complementary Activities
for Increasing the Effectiveness of Requirements Verification and Validation.
Proceedings of ACM Southeast RegionalConference. 2005. 256 – 261.
25. Hornbæk, K., Haegh, R. T., Pedersen, M. B., and Stage, J. (2007). Use Case
Evaluation (UCE): A Method for Early Usability Evaluation in Software
Development. In Baranauskas, C. (Ed.) , Palanque, P. (Ed.), Abascal, J. (Ed.),
Junqueira Barbosa, S.D. (Ed.) Human-Computer Interaction – I#TERACT 2007.
(pp 578-591).Heidelberg: Springer Berlin.
26. OMG Unified Modeling Language Specification. (1999). Retrieved On February 4,
2009, from http://www.scribd.com
27. ADVISE Requirement Management Plan, HEITECH Application Development
Methodology Repository, 2009.
28. HEITECH Project Deliverables. Retrieved On October 21, 2008, from
