CC BY-NC-ND
34
Prioritization of requirements for effective support of the communication process with customers of a commercial bank
Tatiana K. Kravchenko
Professor, Head of Department of Business Analytics National Research University Higher School of Economics Address: 20, Myasnitskaya Street, Moscow, 101000, Russian Federation E-mail: tkravchenko@hse.ru
Sergey N. Bruskin
Associate Professor, Department of Business Analytics National Research University Higher School of Economics Address: 20, Myasnitskaya Street, Moscow, 101000, Russian Federation E-mail: sbruskin@hse.ru
Abstract
Requirements prioritization is performed by business analysts in order to analyze stated requirements and to define the required capabilities of a potential solution that will fulfill stakeholder needs. During the analysis, the business analyst transforms needs and informal concerns of stakeholders into formal solution requirements which describe the behavior of solution components in sufficient detail. Furthermore, requirements analysis may be performed to develop models of the current state of an organization. These models can be used in order to validate the solution scope with business and stakeholders, to analyze the current state of an organization to identify opportunities for improvement, or to assist stakeholders in understanding that current state.
The requirements prioritization task includes the following elements. First, these are business cases which state key goals and measures of success for a project or organization. Priorities should be aligned with those goals and objectives. Business needs can be used as an alternative to the business case if no business case has been defined. Second, the prioritization requires that these requirements have been stated by stakeholders. Third, the list of stakeholders, annotated with their levels of authority and influence, is used to determine which stakeholders need to participate in prioritization.
As a result, the several techniques and recommendations stated in the BABOK® Guide have been applied for requirements prioritization in a case study of a conventional commercial bank. The business needs of the organization have been identified. The main problems of the communication management process have been formulated. Underlying sources of the problem have been illustrated on a fishbone diagram (also known as an Ishikawa or cause-and-effect diagram). The list of stakeholders and the requirements have been made. The MoSCoW technique has been applied in order to identify four groups of requirements, which differ from each other by the impact the results of their implementation have on the solution of the identified problems. The list of prioritized requirements should be used on the next stages of the project. It may be useful for the project manager when planning works on the solution implementation. The results of this work should also help the stakeholders develop a common point of view on the strategic goals of the project.
Key words: requirements, requirements prioritization, fishbone diagram, MoSCoW technique.
Citation: Kravchenko T.K., Bruskin S.N. (2017) Prioritization of requirements for effective support of the communication process with customers of a commercial bank. Business Informatics, no. 2 (40), pp. 7-16. DOI: 10.17323/1998-0663.2017.2.7.16.
Introduction
Both increasing level of competition and current economic difficulties are forcing the banking business to move from price-based competition towards a customer-centric one. More and more banking institutions are implementing a CRM (Customer Relationship Management) concept on both operational and analytical levels. However, the initial complexity and inconsistency of banking systems cause a number of difficulties during the implementation of any new module into the existing IT infrastructure of the organization.
These difficulties are imposed on usual constraints associated with any project, such as budgetary, temporal, or qualitative constraints. In this regard, it is not enough to identify key requirements of the future solution while planning activities on implementing new modules in the IT infrastructure. The fulfillment of all the identified requirements is likely to violate one or several project constraints. Therefore, a process of requirements prioritization is one of the key stages of the requirements analysis process. Prioritization of requirements ensures that analysis and implementation efforts focus on the most critical business requirements [1—6].
The following work provides the results of requirements prioritization in a case study of a conventional commercial bank. The work objective is to put into practice requirements prioritization techniques which are suggested in "A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide)". The object of the study is the process of customer communication management established in the bank. The subject being analyzed is the list of requirements set by the various divisions of the bank for the developing communication support system.
1. Determining the reasons preventing the bank from achieving target sales figures
The leading business activity for the bank being considered was consumer lending in partnership with large retail chains and small regional companies. Recently a new strategic development course has been chosen, with the goal of increasing the loan portfolio by means of diversifying credit products. Since the level of competition in the market of general purpose loans is high, they decided to enter the market by means of cross-selling. This sales method, which implies loan offers to existing customers, was chosen for its relative cheapness and ease of implementation.
Nevertheless, some time after the new strategic development course was approved, it became clear that the hoped-for increase in the amount of general purpose loans to existing customers could not be fulfilled. In order
to determine possible underlying sources of the problem, a root cause analysis was performed by graphing a fishbone (also known as Ishikawa) diagram (Figure 1). This tool helps to focus on the cause of a problem versus the solution and organizes ideas for further analysis. The diagram serves as a map depicting possible cause-and-effect relationships [2].
2. Identification of problems in setting up communications with the bank's clients
Because of the fact that the cross-selling mechanism is based on continuous communications with the bank's customers, the main sources of the problem were discovered in areas of planning and implementing communications with customers, which in turn stem from the technical imperfection of the communication management system available in the bank.
As part of the cross-selling process established in the bank, the following mechanism of planning and implementing communications was used. Clients could be offered a new credit product via e-mail messages, sms messages, and phone calls.
Because of the intensive growth of the bank's client base, as well as the increase in the share of general purpose loans in the overall loan portfolio of the organization, the problems of the existing solution for setting up communications with clients that hampered the further development of cross-selling became obvious:
♦ the inconsistency of the systems used to plan and implement communications (each of the three types of communications was supported by separate and unrelated systems). At the same time, there was a need to make a centralized decision to conduct all types of communications in order to consistently develop relations with the bank's clients and to harmoniously increase the client base without distortions to a particular client segment;
♦ the processes of marketing communications management were automated on a low level. For instance, employees of departments responsible for different stages of the process often had to manually create files, format them and put them in the necessary directories;
♦ the marketing communication management processes were not flexible enough to comply with rapidly changing risk and communication policies of the bank. Lack of flexibility led to situations where the communication strategy chosen for a certain customer at the beginning of month did not correspond with the real credit offer to the customer at the moment of contact.
Fig.1. The cause-and-effect diagram
All the stated problems along with the new strategic development course chosen by the bank top management established a new business need of the organization. The need was to obtain a new tool that supports a centralized, automated, and flexible communications management process. It was decided to develop a unified information system for managing client communications which will completely replace some outdated modules and will also eliminate restrictions which exist in other modules.
3. Identification of stakeholders for the development of a module to support processes of interaction with customers
In Table 1, stakeholders of the project to develop a communication process support system are shown. The stakeholders' roles and responsibilities in the process of communication formation and execution are listed (in parentheses in the field "Stakeholder" the abbreviations for the names of divisions are shown to be used in prospect).
Table 1.
List of stakeholders
Stakeholder Role in the process Level of interest Level of influence
Customer Service Department (CS) The division executes the major part of the direct contacts with customers. It is responsible for delivery of both sms and e-mail messages, incoming line support, and outbound call-down. The division is an owner of the Customer Service process High High
Cross Sales Management Department (XS) The division forms the list of contacts for further call-down on sales topics. It is responsible for the upper-level communication strategy and for customer relationships development. The division is an owner of the Cross Sales process High High
Card Portfolio Management Department (CP) The division is responsible for communication strategy development with the card owners of the bank High Medium
Remote Sales Management Department (RS) The division is responsible for the development of the Internet and mobile bank. It uses sms- and e-mail mailing technologies to attract customers to the new remote sales channels Medium Medium
Information Security and Anti-Fraud Department (AF) The division is responsible for setting up and sending out validation messages in cases when the customer performs one of the key actions: product activation, transaction execution, initiating a change of personal data, establishing a personal cabinet in the Internet bank, etc High High
Collection Department (CL) The division is an owner of the Arrears Collection process Low Low
In order to better understand the subject area and the boundaries of the future solution, we interviewed representatives of each of the selected stakeholder groups involved in the communication management process [1]. Table 2 provides information on all types of communications with clients established in the bank. The owners and executors of the communications are also shown.
4. Functions of the bank for communication with customers
The communication activities that are established in the bank can be divided into several groups by their functions. The primary function of communication with customers is to offer them a new loan product; thus, the process of contact with the client is directly related to
achieving the organization's strategic goal, which is to increase the share of general purpose loans in the total loan portfolio of the bank.
The second function of the communication process with customers is related to maintaining a stronger relationship with clients who already have an active product of the bank. Thus, the communication process is aimed at positively influencing the level of customer loyalty, which, in its turn, positively affects the company's future earnings. Communications concerning customer awareness of information security and countering fraud can also be called as actions aimed at increasing customer loyalty level. Activities aimed at informing clients of their arrears are considered in this case to be increasing the level of communications consistency. For instance, while forming a new message to the client, it is neces-
Table 2.
Types of communication established in the bank
Area Goal Stakeholder Channel of communication Communication description
o To increase the volume of card transactions Card Portfolio Management sms, e-mail, call Informing the client of the bonus program
EE o GO To increase the amount of sales Card Portfolio Management, Cross Sales Management sms, e-mail, call Informing the client of current offers
CD OO To increase the amount of sales Remote Sales Management Internet bank Informing the client of current offers
To raise customer awareness Customer Service sms, call Informing of progress status for the client's appeal
ustome service To increase the customer Customer Service sms, call Providing information on the current status of payments at the request of the client
loyalty level Customer Service sms, call Sending a reminder of a planned visit to the office
oc _Q CO To raise customer awareness Card Portfolio Management, Cross Sales Management sms, e-mail Sending transactional status messages
i 1 o Ë £ To increase the level of penetration of the Internet bank Remote Sales Management sms, e-mail Informing the client of the existence of arrears according to GIS GMS data
o -.¡3 J= CO To increase the customer loyalty level Card Portfolio Management sms, e-mail Informing the client about the card readiness status
"O Information Security sms Notification of client data changes
er m to st To improve customer data Information Security sms Sending card validation requisites
u c Oí c= security level Information Security e-mail Sending information letters on countering fraud
cu e CO Remote Sales Management, Information Security sms Sending Internet bank actions validation requisites
s To raise customer awareness Collection sms, call Sending a reminder of payment
S "o To issue a warning Collection sms, call Informing the client of 5 and 1 days before reaching the debt
£= io ct CD Collection sms, call Informing the client of existing arrears
O O To enforce legislation Collection sms, call Informing the client about transfer of the case to a collection agency
sary to make sure that its content will not contradict the current status of the client and will not mislead the customer. Indirectly, this function of communication with the client can also be attributed to the group aimed at increasing customer loyalty.
5. The problems of the bank's communication with customers and requirements of stakeholders for a future solution
The stakeholder requirements for the future solution are presented in the format of business initiatives, in which each of the stakeholder groups tried to formulate the problems facing the division while performing communication activities and the requirements for their solution (Table 3). The problems facing the stakeholder groups were identified during brainstorming of the divisions' employees [2].
6. Need to prioritize requirements
In view of the project's time limits, resource and financial limitations of the project, the list of stakeholder requirements should be systematized, and the relative importance of each requirement should be determined. These priorities will be used in order to determine which requirements should be implemented first during the development of the communication process support system.
During the process of prioritizing the requirements of stakeholders, it was decided to assess the received requirements in terms of the urgency of their implementation. Since the initiative to develop a new communication module comes from the business sector, which is responsible for increasing the share of cross-sales in the bank's portfolio, it is necessary to make sure that the requirements being implemented are primarily aimed at increasing the amount of general purpose loans and solve the fundamental problems formulated during the process of identifying the business need. In this case, the highest priority of the requirement will mean that this requirement must be implemented at the earliest possible stage of the project.
The main problems identified in a communication management process of the bank (Figure 1) boil down to the technical limitations of the existing communication support system, which:
cause difficulties in the process of forming communications with customers;
complicate the process of implementing planned communications;
reduce the level of customer loyalty level due to ex-
cessively frequent, contradictory and irrelevant communications.
It is advisable to assign the highest priority to requirements whose implementation contributes to the elimination of technical imperfections in the communication support system and makes the existing processes of forming and implementing communications with customers more efficient. Requirements whose implementation involves adding new functionality to the system or contributing to the emergence of new types of communication with customers can be postponed until the next round of system development.
7. Ranking requirements according to the MoSCoW methodology
In order to assess the value of the requirements in terms of their compliance with the main business goals set for the future solution, the requirements have been ranked using the MoSCoW (Must, Should, Could, Will not) analysis technique [2; 3], where:
♦ Must — requirements that must be satisfied in the final solution for the solution to be considered a success. We consider it mandatory to fulfill the requirement in case its implementation contributes to increasing the efficiency of the processes of both forming and implementing communications simultaneously, and also directly increases the loyalty level of the bank's clients;
♦ Should — high-priority items that should be included in the solution if possible. We consider it desirable to fulfill the requirement in case its implementation contributes to the efficiency of either the formation process, or the process of implementing communication with the subsequent increase in the level of customer loyalty;
♦ Could — a requirement which is considered desirable but not necessary. We consider it desirable but not necessary to fulfill the requirement in cases when implementation contributes to the efficiency of either the formation process, or the process of implementing communication;
♦ Won't or Would (W) — the requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future. The fulfillment of such requirements does not directly affect the solution of the priority problems identified in the analysis. The value of implementing them more likely refers to the expansion of the possibilities of communication with customers, rather than addressing current problems in the processes of forming and implementing communications.
Table 3.
Stakeholder requirements
Stakeholder Problem Requirement Short sign
Cross Sales Management Department The inability to directly put the list of target audience of the campaign into the sms message gateway. As a result, files are transferred manually on a daily basis To automate the process of downloading the client database to the gateway directory for sending sms messages, excluding manual file sharing between XS and CS units XS1
Cross Sales Management Department The inability to send e-mail messages over the entire existing client database through the existing system due to the technical limitation on the number of messages sent To add an e-mail channel as a full-fledged communication channel with the client, and to remove technical restrictions on the number of message recipients XS2
Cross Sales Management Department The existing technical restriction on the speed of sending e-mail messages (up to 200,000 messages per month), which impedes the full use of the communication channel To increase the speed of sending e-mail messages to 1 million per hour with the ability to adjust the speed of sending both before the initiation of communication, and directly during the dispatch XS3
Cross Sales Management Department The inability to automatically add the client to the stop-list in case he/she refused to receive messages via e-mail To automatically update the stop-list with information about clients' refusals to receive e-mail messages. To add the new e-mail address to the stop-list in case of changing client contact data XS4
Cross Sales Management Department The inability to get e-mail delivery statistics (delivered / read / target action done), which impedes the full analysis of the communication and its further improvement To provide an opportunity to generate a report on the status of e-mail messages delivery XS5
Customer Service Department There is no information on customer communications in the CRM system To connect the communication module with the CRM system in order to provide information on all the communications carried out with the client in online mode CS1
Customer Service Department There is no possibility to identify incorrect / nonexistent e-mail addresses and phone numbers in the client database To provide an opportunity to centrally form the list of invalid contacts, and the possibility to set the rules by which contacts fall into the invalid list CS2
Customer Service Department The number of communications in which the client is involved exceeds the acceptable level. The situation leads to a decrease of customer loyalty level To provide an opportunity to control the intensity of the client's participation in communications through all channels CS3
Customer Service Department There are no pre-configured limits on the budget for communication for each cost-center, as well as there is no system of alerts / prohibitions on dispatch in case of budget excess To track information on budget spent on communications in online mode, to set up notifications when approaching the threshold value CS4
Collection Department There is no possibility to change or stop sending sms messages during the day when the status of the customer's debt changes The ability to change communication with the client online in the event of changing its status of debt CL1
Collection Department There is no detailed information on the type and the source of sms message in existing reports To implement a unified communication reference book CL2
Collection Department There are no unified reports on customer communications held within the same campaign but by means of different communication channels To log multi-channel communication actions within a single campaign CL3
Card Portfolio Management Department The inability to support real-time message sending in order to quickly react to card transactions made by the customer To integrate the communication module being developed with both CRM (Customer Relationship management) and RTM (Real Time Marketing) systems CP1
Card Portfolio Management Department The lack of a tool to automatically inform the client of the readiness status of the reissued cards To connect the communication module with the credit cards database in order to automatically send messages in accordance with the status of the client's card CP2
Remote Sales Management Department The department is forced to manually create a list of customers who have left an application for an incoming call on a service line on the bank's website To integrate the CRM system outbound module with the bank's website form by means of the new communication module RS1
Information Security and Anti-Fraud Department The department is forced to manually confirm the relevance of clients' personal data in cases when changes have been made in the verification system To automatically update the client data in cases when changes have been made in the verification system AF1
Information Security and Anti-Fraud Department There is a 1-hour delay between the client's activation action with the credit card and the sending of the validation message to him/her to confirm the action. The situation leads to a decrease of the card activation rate To reduce the response time for card activation requests up to 5 minutes AF2
Information Security and Anti-Fraud Department The inability to directly download the client database with the suspicious activity indicator from AFSF to sms messages or outbound calls gateway; as a consequence, the need to use additional CS resources to transfer files manually To automate the process of downloading the client database to the gateway directory for sending sms messages, excluding manual file sharing between AF and CS units AF3
Table 4.
MoSCoW priority matrix
Requirement code Requirement description Justification of the requirement assessment 1 m S 1 W
XS1 To automate the process of downloading the client database to the gateway directory for sending sms messages Implementation of this requirement will save human resources of both XS and CS units, however it will not directly lead to the simplification of communication planning and implementation processes, nor will it contribute to increasing the level of customer loyalty X
XS2 To add an e-mail channel as a full-fledged communication channel with the client The implementation of the requirement will remove the existing restriction on the number of target audience for the communication, which will facilitate the implementation of communication, as well as attract new loyal customers X
XS3 To increase the speed of sending e-mail messages to 1 million per hour with the ability to adjust the speed of sending The implementation of the requirement will help optimize the use of CS department human resources, will increase the flexibility of the process of interaction with customers, and will increase the level of customer loyalty X
XS4 To automatically update the stop-list with the information about clients' refusals The implementation of the requirement will lead to an increase in the consistency level of communications, which positively affects customer loyalty level and is helpful for reducing costs X
XS5 To provide the opportunity to generate a report on the status of e-mail messages delivery The implementation of the requirement will increase the efficiency of the processes of forming and implementing communications with customers X
CS1 To connect communication module with the CRM system The implementation of the requirement helps to increase the level of customer loyalty, since it will reduce the number of uncoordinated and inconsistent communications with the clients X
CS2 To provide the opportunity to centrally form the list of invalid contacts The implementation of the requirement will improve the coherence of communications, reduce costs, and simplify the processes of communications formation and implementation X
CS3 To provide the opportunity to control the intensity of the client's participation in communications The implementation of the requirement will improve the coherence of communications, reduce costs, and simplify the processes of communications formation and implementation X
CS4 To track information on budget spent on communications in online mode The implementation of the requirement will reduce costs, and simplify the processes of communications formation and implementation X
CL1 To connect the communication module with the customer debt database The implementation of the requirement will reduce the response time to the client's status change (which increases the level of customer loyalty), and will reduce the level of inconsistency of data in different modules of the communication management support system X
CL2 To implement the unified communication reference book The implementation of the requirement will increase the level of coordination between various communications of different divisions, and also will reduce the costs of the processes of communication formation and implementation X
CL3 To log multi-channel communication actions Implementation of the requirement will save human resources of the CL unit, however, it will not affect the effectiveness of the processes of communication formation and implementation in a positive way x
CP1 To integrate the communication module being developed with both CRM (Customer Relationship management) and RTM (Real Time Marketing) systems The implementation of the requirement will increase the level of customer loyalty. However, it presumes the creation of a new communication channel and will not resolve the problems identified in the existing processes X
CP2 To connect the communication module with the credit cards database The implementation of the requirement will help promptly inform clients of the status of the card re-issue. This will positively affect the level of customer loyalty X
RS1 To integrate the CRM system outbound module with the bank's website form by means of the new communication module The implementation of the requirement will save human resources of the RS division. Also, it will positively affect the level of customer loyalty x
AF1 To automatically update the client data in cases when changes have been made in the verification system The implementation of the requirement will help increase the efficiency of the communication formation process, and it will also expand the volume of a valid client base. It will increase the level of client loyalty on account of client data relevance increase X
AF2 To reduce the response time to card activation requests up to 5 minutes The implementation of the requirement will increase the level of customer loyalty X
AF3 To automate the process of downloading the client database to the gateway directory for sending sms messages The implementation of the requirement will increase the speed of response to suspicious activities, which will increase the level of customer loyalty in the existing communication process X
The results of applying MoSCoW technique to the stakeholder requirements are shown in Table 4. There is a priority matrix with the following columns. Stakeholder requirements are briefly formulated in the column "Requirement description". Consequences of the requirement implementation are stated in the column "Justification of the requirement assessment", along with the consistency level of the implementation results for each requirement with the strategic goals of the project. Depending on the power of consistency of results of requirement realization and major business problems, the marks Must, Should, Could or Won't are assigned.
Thus, based on the results of MoSCoW prioritization technique, the primary priority group has been identified. This includes requirements which when implemented contribute to the efficiency of existing communications management processes at a fundamental level, namely:
♦ allows the bank to synchronize data in various modules of the communication support system with customers;
♦ increases the level of correctness of data on the bank's customers.
The requirements that are desirable to perform can be described in the following way:
facilitate partial data synchronization in some modules of the communication support system;
increase the efficiency of the processes of communication formation and implementation.
The requirements that are desirable but not necessary to be fulfilled will increase the level of customer loyalty with regard to communication with them in the context of existing types of interactions, but technological problems of the formation and implementation of communication are practically not solved by them. Such requirements may be implemented when enough resources and time remain.
Requirements for which implementation can be postponed are mainly focused on increasing the level of customer loyalty by adding new types of interaction with clients. Implementation of these requirements is more likely to be useful in the future, when the current problems of communications management processes have been resolved.
Conclusion
This work provides the results of requirements prioritization in a case study of a conventional commercial bank. Several techniques and recommendations stated in BABOK® Guide have been applied. First, all the inputs stated for the task of requirements prioritization have been taken into consideration:
• the business need of the organization has been identified. It may be described as a need to obtain a new tool that supports a centralized, automated, and flexible communications management process;
• based on the description of different communication types established in the organization, the main problems of the communication management process have been formulated. The underlying sources of the problem have been illustrated on a Fishbone diagram;
• the list of stakeholders has been made. It consists of the divisions that are directly involved into the communication management process;
• the list of stakeholder requirements has been made.
The basis for requirements prioritization has been
chosen. It is the consistency level between the results of requirement implementation and the problems present in the current communication management process. The MoSCoW technique has been applied in order to identify four groups of requirements which differ from each other by the impact the results of their implementation have on the solution of the identified problems.
The list of requirements with identified priorities allows to more clearly identify the objectives of the project, including for project sponsors. In this case, the goals of the project are to eliminate technical imperfections of the current system of communication with customers, as well as to facilitate the process of forming and implementing various types of communications.
The list of prioritized requirements may be useful for the project manager while planning works on implementation of the solution. The results of the work should also help the stakeholders develop a common point of view on the strategic goals of the project. Keeping to the list of prioritized requirements will help the organization improve a communication management support system in short time and with consideration of the primary goals of the project. ■
References
1. IIBA (2009) A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide). Version 2.0. Toronto: International Institute of Business Analysis.
2. IIBA (2015) A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide). Version 3. Toronto: International Institute of Business Analysis.
3. IIBA (2013) Agile extension to the BABOK Guide. Toronto: International Institute of Business Analysis.
4. Berander P., Andrews A. (2005) Requirements prioritization. Engineering and managing software requirements (eds. A. Aurum, C. Wohlin). Berlin, Heidelberg: Springer, pp. 69—94.
5. Karlsson J., Ryan K. (1997) A cost-value approach for prioritizing requirements. IEEE Software, no. 14 (5), pp. 67—74.
6. Lehtola L., Kauppinen M., Kujala S. (2004) Requirements prioritization challenges in practice. Proceedings of the 5th International Conference "Product Focused Software Process Improvement" (PROFES 2004), Kansai Science City, Japan, 5—8 April 2004. Berlin, Heidelberg: Springer, pp. 497—508.
Приоритизация требований для эффективной поддержки процесса коммуникаций с клиентами коммерческого банка
Т.К. Кравченко
доктор экономических наук,
профессор, заведующая кафедрой бизнес-аналитики
Национальный исследовательский университет «Высшая школа экономики» Адрес: 101000, г. Москва, ул. Мясницкая, д. 20 E-mail: tkravchenko@hse.ru
С.Н. Брускин
кандидат экономических наук, доцент кафедры бизнес-аналитики
Национальный исследовательский университет «Высшая школа экономики» Адрес: 101000, г. Москва, ул. Мясницкая, д. 20 E-mail: sbruskin@hse.ru
Аннотация
Приоритизация требований выполняется бизнес-аналитиком для анализа заявленных требований и определения необходимых возможностей потенциального решения, которое будет отвечать потребностям заинтересованных сторон. В ходе анализа бизнес-аналитик преобразует потребности и неформальные проблемы заинтересованных сторон в формальные требования к решению. Кроме того, анализ требований может быть выполнен для разработки моделей текущего состояния организации. Эти модели можно использовать для проверки области решения бизнеса и заинтересованных сторон, анализа текущего состояния организации с целью выявления возможностей улучшения или для помощи заинтересованным сторонам в понимании этого состояния.
Задача определения приоритетов требований включает в себя следующие элементы. Во-первых, это бизнес-кейсы, в которых указаны ключевые цели и показатели успеха для проекта или организации. Приоритеты должны быть согласованы с этими целями и задачами. Бизнес-необходимость может быть использована как альтернатива бизнес-кейсу, если бизнес-кейсы не были подготовлены. Во-вторых, приоритизация требований требует, чтобы эти требования были заявлены заинтересованными сторонами. В-третьих, должен быть составлен список заинтересованных сторон, участвующих в приоритизации, аннотированный их уровнем полномочий и влияния.
Ряд методов и рекомендаций, изложенных в Своде знаний по бизнес-анализу (BABOK® Guide), применены для нахождения приоритетов требований на примере условного коммерческого банка. Определены бизнес-потребности организации. Сформулированы основные проблемы процесса управления коммуникациями. Основополагающие источники проблемы проиллюстрированы на диаграмме «fishbone» (также известной как диаграмма причинно-следственных связей Исикавы). Составлен список заинтересованных сторон и их требований. Методика MoSCoW была применена для того, чтобы определить четыре группы требований, которые отличаются друг от друга воздействием результатов их реализации на решение выявленных проблем.
Приоритеты требований должны быть использованы на различных этапах проекта, что может быть полезно для менеджера проекта при планировании работ по внедрению решения. Результаты данной работы также должны помочь заинтересованным сторонам разработать общую точку зрения на стратегические цели проекта.
Ключевые слова: требования, приоритизация требований, диаграмма Исикавы, методика MoSCoW.
Цитирование: Kravchenko T.K., Bruskin S.N. Prioritization of requirements for effective support of the communication process with customers of a commercial bank // Business Informatics. 2017. No. 2 (40). P. 7—16. DOI: 10.17323/1998-0663.2017.2.7.16.
Литература
1. A Guide to the Business Analysis Body of Knowledge ® (BABOK® Guide). Version 2.0. Toronto: International Institute of Business Analysis, 2009.
2. A Guide to the Business Analysis Body of Knowledge® (BABOK® Guide). Version 3. Toronto: International Institute of Business Analysis, 2015.
3. Agile extension to the BABOK Guide. Toronto: International Institute of Business Analysis, 2013.
4. Berander P., Andrews A. Requirements prioritization // Engineering and managing software requirements / Eds. A. Aurum, C. Wohlin. Berlin, Heidelberg: Springer, 2005. P. 69-94.
5. Karlsson J., Ryan K. A cost-value approach for prioritizing requirements // IEEE Software. 1997. No. 14 (5). P. 67-74.
6. Lehtola L., Kauppinen M., Kujala S. Requirements prioritization challenges in practice // Proceedings of the 5th International Conference "Product Focused Software Process Improvement" (PROFES 2004). Kansai Science City, Japan. 5-8 April 2004. Berlin, Heidelberg: Springer, 2004. P. 497-508.
