Content uploaded by Salihu Ibrahim Anka
Author content
All content in this area was uploaded by Salihu Ibrahim Anka on Mar 20, 2018
Content may be subject to copyright.
2nd National Research and Innovation Conference (NRICon2016) at Kuching, Sarawak, Malaysia
Improved Service Responsibility Table of Users’ Requirements for
E-Service Systems
Ibrahim Anka Salihu1, a*, Ali Selamat2,b
Abstract. In recent years, UML has been criticized by several researchers and practitioners for its
complexity and lack of comprehension. This has caused difficulties in using UML to analyse e-
service system. As a result of this Service Responsibility Tables (SRT) was proposed as a tool for
analyzing e-service systems. The use of business terminologies in SRT that can be easily understood
by business professionals can encourage user involvement in requirement analysis. In this paper we
used SRT to analyse Graduate Studies Management System as a case study to access the usefulness
of SRT to business professionals. However, the present SRT provide only two approaches to
transform the SRT to use-case and class diagrams. Therefore, we propose some improvements for
transforming the SRTs to activity diagram and sequence diagram respectively. Based on the
evaluations by users, we found that the SRT can improve user participation in requirements
determination process.
Keywords: System analysis, E-Service systems, Requirements elicitation, Requirements
documentation, Service Responsibility Tables (SRT), Unified Modeling Language (UML).
1 Introduction
The popularity of internet and the spread of other electronic technologies have transformed
businesses through the appearance of e-service phenomenon. This has led to increasing demands in
the development of e-service system. E-service system is an information system that is used in
organizations and businesses in order to improve their performance in service delivery within and
outside the organization. E-service has been defined as acts or performances that are delivered
through electronic devices and networks to help people complete tasks, solve problems, or conduct
transactions [1]. E-service has been used as an important tool in the process of capturing business
knowledge and experience with respect to flow of information within and outside the organizations
and it can be the determining factors of the success of businesses [23, 3]. Despite the growing
demand in their development and usage, several failures have been recorded in e-service systems [4,
5] such as failure of the Health Information system in U.K., South Africa, China and some public
sector IS in Thailand [6, 7]. It has been observed that one of the leading cause of system failures are
failures from requirements determination [8]. This has made the development of e-service system to
be more challenging [1].
Corresponding author
Ibrahim Anka Salihu*
1,2 Software Engineering Research Group (SERG), Faculty of Computing,
Universiti Teknologi Malaysia, Malaysia
ae-mail: isankah2@yahoo.com
be-mail: aselamat@utm.my
2nd National Research and Innovation Conference (NRICon2016) at Kuching, Sarawak, Malaysia
Requirements determination (RD) is the processes of gathering, determining, extracting, or
exposing software requirements [9]. It is usually done in the early stage of system analysis and
design by the system analyst. The task involves eliciting and representing users’ requirements in
various representation models, using various format or notations provided by Unified Modeling
Language (UML). The generated requirements models need to be reviewed and validated by the
stakeholders to ensure the success of system implementation [8, 10, 11, 12].
In spite of the general emphasis and wide spread agreement on user involvement in systems
analysis phase, the level and quality of user involvement is inadequate due to various issues, such as
difficulties in identifying requirements and lack of comprehension of UML by business
professionals [13]. The intended users of the system have difficulty in identifying and describing the
capabilities of the proposed system and the actual features they want [13]. Secondly, the industry
standard modeling tools such as UML are used to represent requirements which the users have to
revise. This creates difficulties for the business professionals (managers and users) in understanding
the requirements presented informal notations of UML [14]. Therefore, users can not contribute
positively to the requirements gathering process. Several approaches were proposed for improving
users’ requirements documentation as a solution to the problems in UML, such as in [8, 27].
Another recent approach is Service Responsibility Tables (SRT). Service Responsibility Tables
(SRT) represents users’ requirements in service vocabulary that will clearly show the business
processes replacing the use of jargons as in UML. This will encourage participation of stakeholders
and enable them to negotiate and validate their requirements with the system analyst. However,
there is a limitation with the existing SRT due to lack of approach to transform it to other UML
diagrams (activity and sequence) for further analysis. The existing SRT has only defined two
heuristics to transform it to use case and class diagrams. However, several models are used to
represent different requirements in systems analysis stage such as activity, sequence, state chart etc.
Therefore, in this paper we proposed an improve SRT with a heuristic approach to guide the
transformation to activity and sequence diagrams.
This paper is organized as follows: Section 2 is a review of UML problems in analyzing e-
service systems. Section 3 presents the methodology and a case study on application of SRT to
analyze e-service systems. In section 4 we proposed a heuristic approach to transform the SRTs to
activity and sequence diagrams which is our main contribution. Section 5 presents discussion and
conclusion.
2 Related Works
There are several problems affecting requirements determination for information systems such
as; 1) the constrain of humans as information processors and problem solvers, 2) the variety and
complexity of information requirements, 3) the complex pattern of interaction among users and
analyst, 4) the unwillingness of users to provide requirements [9, 15]. Furthermore, others problems
are believed to be communication obstacles among users and between users and analyst [16]. These
obstacles in communication are attributed to inconsistency in frame of reference among
stakeholders in system analysis and design [1]. Such frame of reference is leveled by Orlikowski
and Gash [17] as technological frames that are vital to understanding the variety and complexity of
user’s needs. We can therefore deduce that communication problems greatly affect user’s
involvement in requirements analysis. The related works discussed the problems of using Unified
modeling Language (UML) in analyzing the e-service systems. It also discussed how the light
weight analysis tool SRT could improve the documentation of requirements for e-service systems.
2.1 The problems of using UML to analyse e-service systems
Since its adoption by the Object Management Group (OMG) 1997, UML has been widely
accepted as a modeling standard for object oriented software development and has been diversely
2nd National Research and Innovation Conference (NRICon2016) at Kuching, Sarawak, Malaysia
used to analyse different kind of systems [8, 18]. UML is a language with rigorous syntax and
grammar [1, 2, 10, 19] that makes it difficult for business professional and novice developers to
understand. The difficulties lead to inadequate user involvement in requirement determination
process. UML notations are often shown in number of ways that can easily confuse a novice analyst
[20]. Siau and Loo [21] identifies two categories of problems in UML which are the inherent and
peripheral problems that cause difficulties in the learning process by the novice analyst.
UML lacks comprehension by business professionals and even with UML knowledge, usually
important business requirements are missing when taken out of business context and expressed in
visual notation [22]. A case study by Glinz [14] has revealed several deficiencies of UML as a
requirement specification language. A survey of UML usage by practitioners has shown that the
usage of UML by practitioner is lower than expected due to the following problems. The complexity
of UML leads to the difficulties in learning UML diagrams for both IT professionals and clients.
Furthermore, it brings communication difficulties between users and analyst. The problems of UML
pose challenges to user involvements and contribution in the various stages of information
requirements determination [1].
UML uses notation to represent business process, and when business process are taken out of
business context and represented in diagrams or notations, some of the important business processes
could be lost and business professionals may not understand them [1, 22, 24]. According to Tan,
Alter et al. [1] UML emphasizes on the use of technical artifacts and the diagrams that are used for
modeling requirements have deficiencies in representing the requirements accurately, especially the
non-functional requirements. In conclusion, UML lacks clearly defined syntax and semantics [19,
25] which can affect its comprehension [10]. The inconsistencies in the designs of UML can lead to
inaccuracy in the design [26] and inaccuracy in representing information [24]. These problems of
UML affect the user involvements, identification and specification of users’ requirements for the e-
service systems.
2.2 Service Responsibility Tables
To address the long standing problem of inadequate user involvement and inadequate
business/IT alignment, there is the need to give greater attention to service concept and metaphors
[25]. There is the need for light weight techniques or tools for business professionals that will help
them understand business situation and potential implication of any proposed change to the system
[13]. Discussing users’ requirements in service vocabulary that will clearly show the business
processes will improve users’ participation in system analysis. Moreover, to better understand
service systems we need to focus on the activities and responsibilities of both service providers and
service customers. This is because “the value of service is often co-produced jointly by the service
provider and the service buyer” [25]. In view of this, the work system approach (which was
developed to help business professionals understand, evaluate, and analyze systems in
organizations) was extended to incorporate the unique characteristics of service [19, 28] which led
to the development the tool called service value chain framework [19].
Service responsibility tables is a light weight analysis tool developed based on the concept of
service value chain framework. it is designed to accommodate the activities and responsibilities of
both service providers and customers based on the broad observation that service tends to be co-
produced by service producers and service consumers [25]. It has two columns swim-lane adapted
from service value chain framework, one for service producer and the other for services customer.
The flexible format of SRTs allows easy re-user of the columns to generate additional columns for
any topic that might be important as the analysis proceeds [1].
3 Methodology
Improving the documentation of requirements for e-service systems depend on the quality of user
involvement in requirement analysis and the tool used in the process. However, the tool used posed
2nd National Research and Innovation Conference (NRICon2016) at Kuching, Sarawak, Malaysia
challenges to user involvement. Service Responsibility Tables was developed to bridge the gap
between IT professionals and business professionals. An empirical investigation of usability of SRT
in analyzing e-service systems was conducted by using it to analysis Graduate Studies Management
System (GSMS) as a case study. GSMS is a university system that allows prospective applicants to
apply for admission in the university, the application will be processed by the School of Graduate
Studies and notify the applicant of status of their application. The system also keeps record of
students’ academic records, financial and study status. This research focuses mainly on the graduate
admission process.
The stakeholders of GSMS are spread across many departments of the school. This comprises of
users from School of Postgraduate Studies (SPS), International Student Centre (ISC), faculties,
bursary and Center of Information and Communication Technology (CICT). Intake unit in SPS is
mainly responsible for managing admission process in the school which is part of the functions of
GSMS. Therefore, staffs of the unit ware used for the requirements determination process. Recent
researches indicates that applying work system approach (e.g. work system frame work and work
system snapshot) is helpful to non-technical individuals and will be useful for understanding and
summarizing systems in organizations [16, 17]. We used work system snapshot in the initial stage
of analysis to eliminate the lack of clarity and confusion in using only SRT. The proposed method
involves four steps that will be undertaken by analyst and stakeholders. They are; identify
stakeholders, create work system snapshot (WSS), create SRT from WSS and design UML
diagrams
3.1 Application of SRT
The four steps discussed in previous section are conducted in sequence. After identifying
stakeholders of the system, they jointly create a WSS of GSMS as shown in table 1.
Table 1: Work system snapshot for Graduate Studies Management System (GSMS)
Customers
Products and Services
• Applicant
• Assistant Registrar
• Intake clerk
• Admission
• Offer letter
• Rejection letter
Processes and Activities
• SPS Maintain courses information
• Applicant create account
• Applicant login using account id
• Applicant submit application
• Intake clerk checks applications
• Intake clerk notify applicant receive of
application
• Intake clerk informs applicant of
incomplete application
• Assistant Registrar checks applicant’s
qualification and University’s recognition
• Assistant Registrar send Phd. applications
and Masters by research to faculties
• Assistant Registrar receives confirmation
from faculty
• Admission committee decides on
applications
• Intake clerk update applications' status
• Intake clerk send notification to applicants
• Applicant receives notification
• Applicant send response
• Intake clerk receives response from
applicants
• Intake clerk inform faculties names of
successful candidates
Participants
Information
Technologies
• Applicant
• Assistant
Registrar
• Courses offered in the
school
• Entry requirements
• Notification letter
• List of applications
• List of Institutions
• GSMS
• Internet
• Telephone
2nd National Research and Innovation Conference (NRICon2016) at Kuching, Sarawak, Malaysia
• Admission
committee
• Intake clerk
• Applicants’ email
• Application
• Applicant’s information
• Applicant’s credentials
• Decision on application
• Research proposal
• Supervisor information
• Offer letter/rejection letter
• Notification letter
• Response letter
The process and activities in work system snapshot in table 1 are used to create the SRT by
distinguishing activities and responsibilities of both provider and customer placing them in the
designated columns in SRT as shown in table 2. The column for information in table 1 can be used
to create additional column for information used or generated in column four of the SRT.
Table 2: Service Responsibility Table for Graduate Studies Management System (GSMS)
Provider Activities and
Responsibility
Customer
Activities and
Responsibility
Information used
or generated
Triggers and
Communication
1
Maintain courses
information
Applicant identifies
course of interest
Courses title, entry
requirements,
mode, duration
Need for students
2
-
Create account
email address
Need to apply
3
-
login with account
credentials
use email and
password
Need to apply
4
Intake clerk checks
applications
Submit application
Applicant
information,
course of study,
credentials
Request for
admission
5
Intake clerk notify
applicant of received of
application
Receive notice for
received of
application
Notification letter
Receive of
application
6
Intake clerk informs
applicant of incomplete
application
Receive notice of
incomplete
application
Application/
credentials
To complete
application
7
Asst. Registrar checks
applicant’s credentials and
University’s recognition
-
name of
Institutions,
location, country
Verify University
recognition
8
Asst. Registrar send Phd
applications and Masters
by research to faculties
-
Use application
and research
proposal, email
To request
confirmation,
research proposal
9
Asst. Registrar receives
confirmation from faculty
-
Retrieve name of
supervisor, email
Name of
Supervisors
Admission committee
decides on applications
-
Applications
Received
applications,
decision on
applications
10
Intake clerk update
applications' status
-
Decision on
applications
Update
applications status
11
Intake clerk send
notification to applicants
Receive notification
letter
Applicant’s email
address
Notify applicant,
notification letter
12
Intake clerk receives
response from applicants
Send response form
Use response form
response letter
2nd National Research and Innovation Conference (NRICon2016) at Kuching, Sarawak, Malaysia
13
Inform faculties names of
successful candidates
-
List of approved
applications, email
to notify faculties,
list of applicants
4. Transforming SRT to UML diagrams
Service Responsibility Table is introduced as a light weight analysis tool to be used by business
professionals to supplement UML in analyzing systems. It is intended that SRT will be converted to
UML diagrams for further analysis by systems analyst and designers. Tan et al. [13] proposed two
set of heuristics to be used in transforming SRTs to use case and class diagrams. In this study we
have proposed two a additional heuristics to guide the transformation of SRTs to activity diagram
and sequence diagram as in next sections.
4.1 Transforming SRT to activity diagram
Systems analyst design activity diagrams as a means of building business process models. They
are used to model the behavior in a business process independent of objects. Activity diagrams are
workflow diagrams with notations that address the modeling of parallel, concurrent activities and
complex decision processes usually from different use cases. Using the columns for provider and
customer activities in SRT in table 1, we can create activity diagram based on the following
heuristics: a. Identify activities from provider and customer columns b. Identify relationship and
branching flow between the various activities c. Link the activities showing the order of execution
d. Draw the diagram.
Following these heuristics, the SRT shown in Table 1 can be used to generate activity diagram.
The steps below are followed in the transformation:
i. The activities and responsibilities in the first two columns in the SRT in table 1 are as follows:
a. Customer activities; check courses, login or create account for new users, submit
application, receive acknowledgement and receive offer letter of rejection letter.
b. Provider activities; check applications, notify applicant if documents in complete, verify
applicant’s qualification and University, cancel application, confirm admission for
thought course or send application to faculties for phd/research work, send notification,
receive acceptance and update applicant status. These activities make the candidates for
activity diagram. The diagram is drawn in a twin lane to show customer activity and
provider activity
ii. Identify and show parallel, concurrent activities and complex decision processes among the
activities. Create account and notify applicant of incomplete documents are conditional
activities, verify applicants’ qualification and university are concurrent activities and cancel
application, confirm admission for thought course or send applications to faculties are
decision activities.
iii. Link the activities as identified showing all the relationship.
2nd National Research and Innovation Conference (NRICon2016) at Kuching, Sarawak, Malaysia
Customer Activity Provider Activity
Check course
Create
account
Login
Submit
application
Receive
acknowlegement
Receive offer
letter
Send acceptance
Receive
rejection
letter
Check
applications
Inform
applicant to
complete
documents
Verify
applicants'
qualification
Verify
applicants'
University
Cancel
application
Confirm
admission
Msc tought
Send Phd
& Msc
research to
faculties
Send offer
letter
Receive
acceptance
Update student
status
Send
rejection
letter
sd Admission
Applicant Ass.Registrar Institution:InstitutionList
Faculty:faculties
SubmitApplication()
ApplReceived() [CourseConfirm]LookupIns
titution()
RequestConfirmation(ResearchProposal)
[RequestConfirmed]nameOfSupervisors()
SendNotification()
SendResponseLetter
() NotifyFacultyofSuccessfulApplicants(applicantsInfo)
Intake clerk
DecisionOnApplication()
Figure 5: Activity diagram from SRT Figure 6: Sequence diagram from SRT
4.2 Transforming SRT to sequence diagram
Sequence diagrams are used to show objects that participate in a use case and the exchange of
messages between them over time. It is defined as a dynamic model that shows the explicit
sequence of messages that are passed between objects in a defined interaction. By extending the
SRT to contain a fourth column named triggers and communication we can use the fourth column to
generate a sequence diagram by using the following heuristics: a. Use all the columns of SRT to
identify actors and object that interact with each other and select the ones to participate in the
diagram b. Identify messages and the pattern of message exchange between actors and objects and c.
Link the messages with actors and objects showing the sequence (message send and message reply).
Following the heuristics above, the SRT shown in (Table 1) is used to generate sequence
diagram. The steps for the transformation are identified below:
i. The actors identified from the SRT are; applicant, Ass. Registrar and intake clerk while the
objects are institutions and faculties.
ii. The message exchange between actors and objects are; a. Submit application b. Application
received c.Verify institution d. Request confirmation of admission e. Request confirmed f.
Decide on application g. Issue notification letter h. Response letter i. List of successful
applicants
5. Discussion and Conclusion
Service Responsibility Table can be a useful tool for improving users’ participations in
requirements elicitation/documentation process. The existing SRT provided only two approaches to
transform the generated SRTs to use-case and class diagrams. However, these two diagrams do not
provide all the necessary details required for implementing a system. Therefore, in this paper we
proposed two heuristics for transforming SRTs to activity and sequence diagrams which are other
important diagrams in system analysis and design.
We have applied SRT to analyse GSMS an e-service system in UTM. The proposed heuristics
were applied to transform the SRTs to UML that can be later used by professionals in developing a
system. Based on the users’ perception SRT can be very useful to business professionals in
2nd National Research and Innovation Conference (NRICon2016) at Kuching, Sarawak, Malaysia
analyzing a system and the transformation approach could benefit the users in transforming SRTs to
activity and sequence diagram without the need of a professional.
References
[1] X. Tan, S. Alter, and K. Siau, Using service responsibility tables to supplement UML in
analyzing e-service systems. Decision Support Systems, 51(3): p. 350-360, 2011.
[2] D. Torre, Y. Labiche, and M. Genero, "UML consistency rules: a systematic mapping study." In
Proceedings of the 18th International Conference on Evaluation and Assessment in Software
Engineering, p. 6. ACM, 2014.
[3] J. Santos, E-service quality: a model of virtual service quality dimensions. Managing service
quality, 13(3): p. 233-246, 2003.
[4] S. Swamynathan, A. Kannan, and T.V. Geetha, Composite event monitoring in XML
repositories using generic rule framework for providing reactive e-services. Decision Support
Systems, 42(1): p. 79-88, 2006.
[5] K. Siau and X. Tan, Improving the quality of conceptual modeling using cognitive mapping
techniques. Data & Knowledge Engineering, 55(3): p. 343-365, 2005.
[6] S. Goldfinch, Pessimism, computer failure, and information systems development in the public
sector. Public Administration Review, 67(5): p. 917-929, 2007.
[7] A. Nauman et al. Information Systems Development Failure: A Case Study to Highlight the IS
Development Complexities in Simple, Low Risk Projects in Developing Countries. in
Proceedings of the 2nd International Conference on Innovations in Information Technology.
Citeseer. 2005.
[8] G.J. Browne and V. Ramesh, Improving information requirements determination: a cognitive
perspective. Information & Management, 39(8): p. 625-645, 2002.
[9] H. Saiedian and R. Dale, Requirements engineering: making the connection between the
software developer and customer. Information and Software Technology, 42(6): p. 419-428,
2000.
[10] B. Dobing and J. Parsons, How UML is used. Communications of the ACM, 49(5): p. 109-113,
2006.
[11] T. Jokela et al., The standard of user-centered design and the standard definition of usability:
analyzing ISO 13407 against ISO 9241-11. in Proceedings of the Latin American conference on
Human-computer interaction, ACM, 2003.
[12] S. Kujala, User involvement: a review of the benefits and challenges. Behaviour & information
technology, 22(1): p. 1-16, 2003.
[13] X. Tan and S. Alter, Linking Lightweight and Heavyweight Systems Analysis by Converting
Service Responsibility Tables into UML Diagrams. Special Interest Group on Systems Analysis
and Design, p. 1-10, 2008:
[14] M. Glinz, Problems and Deficiencies of UML as a Requirements Specification Language, in
Proceedings of the 10th International Workshop on Software Specification and Design. IEEE
Computer Society. p. 11, 2000.
[15] D. Truex, et al., Extending a systems analysis method for business professionals, in Practical
Aspects of Design Science. Springer. p. 15-26, 2012.
[16] S. Alter, Service system fundamentals: Work system, value chain, and life cycle. IBM Systems
Journal, 47(1): p. 71-85, 2008.
[17] S. Alter, A Work System Front End for Object-Oriented Analysis and Des. in 11th Annual
Symposium on Research in Systems Analysis and Design, Vancouver, Canada. 2012.
[18] J.R. Valusek and D.G. Fryback, Information requirements determination: obstacles within,
among and between participants, in Proceedings of the twenty-first annual conference on
Computer personnel research. ACM: Minneapolis, Minnesota, USA. p. 103-111, 1985,
2nd National Research and Innovation Conference (NRICon2016) at Kuching, Sarawak, Malaysia
[19] S. Alter, Service Responsibility Tables: A new Tool for Analysing and Designing Systems.
13th American Conference on Information Systems, p. 1-10, 2007
[20] K. Siau and P.-P. Loo, Identifying difficulties in learning UML. Information Systems
Management, 23(3): p. 43-51, 2006.
[21] D. Batra, Unified modeling language (UML) topics: the past, the problems, and the prospects.
Journal of Database Management, 19(1): p. 1-7, 2008.
[22] J. Erickson, A decade and more of UML: An overview of UML semantic and structural issues
and UML field use. Journal of Database Management, 19(3), 2008.
[23] J. Kim, J. Hahn, and H. Hahn, How do we understand a system with (so) many diagrams?
Cognitive integration processes in diagrammatic reasoning. Information Systems Research,
11(3): p. 284-303, 2000.
[24] K. Siau and L. Lee, Are use case and class diagrams complementary in requirements analysis?
An experimental study on use case and class diagrams in UML. Requirements engineering, 9(4):
p. 229-237, 2004.
[25] S. Alter, Viewing systems as services: a fresh approach in the IS field. Communications of the
association for information systems, 26(1), 2010.
[26] Z. Yang and M. Jun, Consumer perception of e-service quality: from internet purchaser and
non-purchaser perspectives. Journal of Business strategies, 19(1): p. 19-41, 2002.
[27] Pitts, Mitzi G., and Glenn J. Browne. "Improving requirements elicitation: an empirical
investigation of procedural prompts." Information Systems Journal 17.1 (2007): 89-110.
[28] Alter, S., The work system method. Connecting People, Processes and IT for Business Results.
Larkspur, 2006.