Download Banking system requirements management and more Lecture notes Information Technology in PDF only on Docsity!
A Case Study of Requirements Management in a bank
Milica Gazivoda , Marija Šćekić and Jelena Nikolić
Faculty of Information Technology, University “Mediterranean”, Podgorica, Montenegro milica.gazivoda@atlasbanka.com marijascekic1982@gmail.com jelena.nikolic@atlasbanka.com
Abstract. Frequency of software projects in banks significantly increases needs for its proper managements. Requirements management (RM) provides an interface between all others developments activities in Requirements Engineering (RE). Very important part of RM is identifying stakeholders. This paper presents the problems and negative outcomes due to inadequate identifying of stakeholders in RM process of one project in case bank, hereinafter referred to as: MN bank.
Keywords: requirements managements, eliciting, identifying stakeholders.
1 Introduction
Consequences of inappropriate Requirements Management (RM) are huge: costs, availability of hardware, software and human resources, impact on other projects etc. In banking systems, Information Technology (IT) departments are perceived just as support for banking processes and activities. Therefore, importance of RM was miss- ing. Having in mind complexity of banks and their constant need for innovations makes banks to strive for successful software projects so as to be competitive on the market. Software requirements are in center of every software projects and every change of requirements reflects on other development phases [1], so they must be well managed. As previously mentioned, RM is process which support other Requirements Engi- neering (RE) processes, from elicitation, analysis, specification to verification of re- quirements [1, 2]. Literature defines RM as “the activity concerned with the effective control of information related to stakeholder, system and software requirements and, in particular, the preservation of the integrity of that information for the life of the system and with respect to changes in the system and its environment” [3]. Another definition is, “Requirements management is a set of activities that help the project team identify, control, and track requirements and changes to requirements at any time as the project proceeds” [4]. Core RE activities are eliciting, modelling and ana- lyzing, communicating, agreeing and evolving requirements [5]. Eliciting refers to definition of system’s boundaries, identifying stakeholders, choosing appropriate techniques which follows elicitation process. Modelling and analyzing consists on enterprise, behavioral, domain, Non – Functional Requirements (NFRs) modelling
and analyzing requirements model. Communicating refers to a process of documenta- tion requirements and facilitating communication among different stakeholders. Agreeing requirements is validation of requirements from all stakeholders. Evolving requirements refers to change management [4, 5]. As every project is specific, appropriate identification of stakeholders is essential for its success. Thus, it represents an important phase in elicitation process because all tasks revolve around humans. Also, its importance is described in literature [3, 4, 5, 6]. This paper presents improper identification of stakeholders in elicitation process for a project in MN bank. The case study refers to a 14 – months’ project. MN bank uses traditional and agile methods of developments, without RM tools. Our proposal is to include identification of stakeholders as a first step in RM process in any subsequent banking projects. Uses of RM tools are also strongly recommended. The rest of the paper is organized as follows: Section 2 describes RM in MN bank; Section 3 presents the empirical study and discusses its results; Section 4 examines related work; and Section 5 concludes the study and summarizes the key findings.
2 Requirements Management in MN bank
MN bank uses widely accepted approach for IT projects managements, Information Technology Infrastructure Library (ITIL) [7], which focuses on results not on tools. According to [7, 8, 9], ITIL consists of five major areas; Service Strategy, Ser-vice Design, Service Transition, Service Operation and Continual Service Improve-ment. Each of them supports other. The ITIL guide [9] states that the center of soft-ware process lifecycle represents Service Strategy area which provides guidance for strategic assets of projects, validity of projects, integration into existing system and functionalities etc. Topics covered in Service Strategy stage refers to both the strategy and organizational review of projects. Service Design provides guidance for design and developments envisaged in previous stage. Service Transition deals with integra- tion of products from previous stages (Service Strategy and Serv ice Design), risk analysis and recovery methods. Service Operations provides guidance for efficient delivery and support of services. At the end, Continual Service Improvement com- bines different methods and technics for adequate quality service management, with focus on continuous improvement of quality [9]. Having in mind the mentioned ITIL standards [7, 8, 9] RE process in bank consists on following phases: requirements elicitation, feasibility analysis, project planning, design, implementation, evaluation and closing requirements. Figure 1 describes re- quirements flow from elicitation to closing in MN bank.
Table 1. List of banking products and services in MN bank RETAIL CORPORATE Accounts with subdivision in relation to Accounts with subdivision in relation to the type of contract the type of contract Overdraft Term deposits Term deposits Loans Loans Guarantees Cards with subdivision in relation to the Letters of credit type (Debit, Credit, Prepaid) E-banking with subdivision in relation to Cards with subdivision in relation to the the type of service (lib, token, sms) type (Debit, Credit) Western Union E-commerce Standing order Pos Acquiring Standing order E-banking with subdivision in relation to the type of service (lib, token, sms)
Teams of programmers perform time assessment for this requirement. Specification is presented in man/hours in the table 2. Deadline for implementation is two months from the day of receipt of time specification.
Table 2. Specification of time required for Requirement I
Description Administration of requirements 1 System analysis 1 Designing 2 Programming Parametrization 0. Database changes 9 Modified forms and librar- (^) 0. ies New forms 3 Testing 7 Total: 24
In testing phase, users discovered deficiencies referring to incomplete list of products mentioned in table 1, as well as poor graphical user interface. The requirement had to be amended. The amended requirement specifies that the products list from table 1 should be updated with two new categories: Business cards and Corporate Prepaid cards. As a solution of poor graphical user interface, at the bottom of product list should be created checkbox so as that the desired products for review could be selected. After specification and approving requirement, it was sent to developers who performed time assessment for it. Time required specification is presented in table 3. Deadline for implementation is two months from the day of receipt of the time specification.
Table 3. Specification of time required for Requirement II
Description Administration of requirements 0. System analysis 0. Programming Parametrization 0. Database changes 0. Modified forms and librar- 1 ies Testing 1. Total: 4.
Testing of the amended requirement is approved as it meets all desired requirements and it was ready to put on production. A case study analysis was performed so as to point out to omissions in RM. We created new requirement which contains data from both previously described requirements. Time required specification for this requirement is presented in table 4.
Table 4. Specification of time required for integrated requirements
Description Administration of requirements 1 System analysis 1 Designing 2 Programming Parametrization 0. Database changes 9. Modified forms and librar- (^) 0. ies New forms 3 Testing 7. Total: 24.
The difference between this requirement and the two sent requirements is 3. man/hours. To high-risky system, such as banks, it is not negligible difference be- cause every m/h unit represents financial cost. Table 5 presents difference in prices.
Table 5. Comparison of prices
Description I+II Integrated Administration of requirements 1.4 1 System analysis 1.4 1 Designing 2 2 Programming Parametrization 0.7 0. Database changes 9.8 9. Modified forms 1.5 0. and libraries
presented in [16] is focused on interaction between stakeholders, instead of relation- ships between the system and the stakeholder. It classified stakeholders into four cat- egories called: baseline, supplier, client and satellite. Main category is baseline and consists of users, developers, legislators and decision-makers. Stakeholders selection framework presented in [17] consist of three stages: Identi- fication, Filtering and Prioritization. Identification refers to project definition (goals, type and domain). Filtering assesses stakeholders’ knowledge and interests, then fil- tering them according that assessment. Prioritization measures stakeholders’ interper- sonal skills and finalize process of stakeholders identification. Reviewed literature presents several approaches to identify the right stakeho lders. In spite of that, there is no appropriate method or techniques available to identify stakeholders that are applicable on all software projects.
5 Conclusion
In this paper we presented RM process in the bank. The case study of inadequate identification of stakeholders in elicitation phase is presented. This lack was identified in testing phase, so the final cost of project has been increased. Also, we pointed out what benefits can have good software requirements specification (SRS) on project. To decrease financial costs and avoid overrun of time limits to realize software projects in bank, author proposes better identification of stakeholders in SRS. Having in mind that IT departments in banking system are interface between users and devel- opers, and commonly key stakeholders in elicitation phase, special attention have to be paid to its’ education. They should have good knowledge of banking concepts and processes so as to be able to understand the requirements of other departments in the bank. On the other hand, they must be aware of technical feasibility of requirements and their integration in existing system. Experience of developers to comprehend requirements sometimes enables them to see what is mentioned in the requirements which in the end speed up the whole process. Future studies may explore approaches for identification stakeholders in order to establish framework for its identification and prioritization in banking software pro- jects.
References
- Wiegers, K., Beatty, J.: Software requirements. 3rd ed. M icrosoft press, Washington (2013).
- Kotonya, G., Sommerville, I.: Requirements Engineering: A Good Practice Guide. John Wiley & Sons, (1998)
- Gothel, O., M äder, P.: Acquiring tool support for traceability. In: Software and Systems Traceability. Springer, London (2012).
- Pressman, R. S.: Software Engineering: A Practicioner’s Approach. 7th^ ed. M cGraw - Hill, Boston (2010)
- Nuseibeh, B., Easterbrook, S.: Requirements Engineering: a roadmap. In: proceedings of the Conference on the Future of Software Engineering., pp. 35-46., Ireland (2000).
- Alexander, I., Dukic, Lj. B.: Software requirements: How to Specify Products and Ser- vices. Wiley & Sons, (2013).
- Heusser, M .: How to get started with ITIL, M ay 2015, http://www.cio.com/article/2926178/systems-management/how-to-get-started-with- itil.html, last accessed 2017/02/
- BM C’s Guide to ITIL: ITIL Processes and Best Practices introduc- tion.,http://www.bmc.com/guides/itil-introduction.html, last accessed 2017/02/
- InformationTechnologyInfrastructureLibrary(ITIL)Guide, http://www.itinfo.am/eng/information-technology -infrastructure-library -guide/, last ac- cessed 2017/02/
- Asseco South Eastern Europe, Banking Operations: BaPo, https://see.asseco.com/banking- and-finance/banking/banking-operations/bapo-528/, last accessed 2017/02/
- M ajumdar, S. I., Rahman, M d. S., Rahman, M d.M : Thorny Issues of Stakeholder Identifi-cation and Prioritization in Requirement Engineering Process. IOSR Journal of Computer Engineering 15(5), 73–78 (2013).
- Hofmann, H. F., Lehner, F.: Requirements engineering as a success factor in software pro- jects. IEEE Software 18(4), 58–66 (2001).
- Rupp, C., Klaus, P.: Requirement Engineering Fundamentals. Rocky Nook, (2011)
- Coughlan, J., Lycett, M ., M acredie, R. D.: Communication Issues in Requirements Elicita-tion; A Content Analysis of Stakeholder Experiences. Information & Software Technology 45(8), 525–537 (2003).
- Anwar, F., Rozali, R.: A Practical Guideline of Selecting Stakeholders for Requirements Elicitation. International Journal of Software Engineering and Its Application 9(5), 95– 106 (2015).
- Sharp, H., Finkelstein, A., Galal, G.: Stakeholder Identification in the Requirements Engi- neering Process. In: Proceedings of Workshop on Requirements Engineering Processes, REP’99, pp. 387–391, IEEE CS Press, Florence, Italy (1999).
- Razali, R., Anwar, F.: Selecting the right stakeholders for requirements elicitation: A sys- tematic approach. Journal of Theoretical and Applied Information Technology 33(2), 250– 257 (2011).
