Keywords

1 Introduction

Business analysis has a long history and as such is root of the subject of management itself. Analysis and diagnosis were always at the beginning of the decision making process. The decision maker was involved in the recognition of context, data, processes, and their outcomes just to recognize the economic solutions or select the best option. Consultants started to provide analysis services to organizations and they were able to work directly with their business clients. Later, business analysts began to be employed to assist managers and to take on some analytics roles, especially in reporting. In this paper, a basic question is what tasks, tools, and decision-making processes belong to business analysts. Therefore, the paper consists of two main parts. The first subchapter covers the presentation of literature review results and discussion on the role of business analysts in information system development processes. The second subchapter concerns the presentation of a case study on Non-Formal Education (NFE) system development at a university. This case study is to reveal the roles, tasks and decisions, as well as tools and techniques used by business analysts. Conclusions cover summarizing the literature review, revealed knowledge gaps and challenges important for business analysts in requirement elicitation and tasks mapping.

2 Systematic Literature Review

Systematic literature review (SLR) is accepted as a research methodology and as such is employed within different disciplines of science as a way to synchronize research findings in a systematic and transparent way. This method is applied as a process for identification of relevant research as well as to reveal the gaps in research studies. Its aim is to recognize all empirical evidence to answer particular questions or to verify hypotheses. In this way, researchers are able to learn which particular issues are challenging. Detailed steps of the research on business analyst’s characteristics and activities are included in Table 1.

Table 1. Detailed steps in literature survey.
Full size table

The fundamental research question was formulated as follows: RQ1: How do business analysts support requirement elicitation? The proposed literature review research method was supplemented by the studies of guidelines on business analysis, i.e., Business Analysis Body of Knowledge (BABOK) [5], CBAP [30], and PMI Guide for Business Analysis [31], and BIZBOK [1]. The fundamental reviews were done using the following databases: Association for Information Systems Electronic Library (AIS eLibrary), IEEE Explore Digital Library (IEEE Xplore), SAGE journals, Science Direct, Scopus, and Web of Science (WoS). The numbers of searching results were summarized in Fig. 1. According to the suggestions on literature review process, at first, taking into account the mentioned above repositories, the phrase “business analyst” was searched. The searching was conducted via the search string “business” AND “analyst”. In the survey, papers and book chapters published in 2009–2020 were included. The reviewed papers classification was carried out by reading the articles and finding references to specific criteria, i.e., requirement elicitation and other tasks of business analysts, their competencies, roles, involvement in bridging the gaps between Information Technology (IT) and business needs, and finally – business analysts’ challenges.

Fig. 1.
figure 1

The selection of articles considered for this research.

Full size image

After the deduplication of founded results and the removal of inappropriate publication, finally, only 21 papers were selected as valuable examples for the discussion on business analyst’ activities. The selected 21 papers were summarized in Tables 2, 3, and 4. According to the survey, there are thousands of papers, which concern analyst activity in different research area. However, only about 200 publications were written on business analyst for business systems. Authors of that papers prefer to write about the objects of business analyses instead about the actors, i.e., analysts. Eventually taking into account popular information system development methodologies, languages and tools, 21 publications are selected as the most suitable for this study. The content analysis revealed the primary activities of business analysts. The requirement elicitation is considered as a fundamental task of business analyst (Table 2).

Requirement elicitation process is a communication process oriented towards mutual understanding, negotiation, problem solution, and partnership cooperation. The business analysts’ competencies are recognized and presented in reviewed literature in Table 3. In the time of business analytics development, the exceptional role belongs to business analysts and they have many new responsibilities, i.e., validation rules, progress reporting, visualization of data structures and algorithms, data collection and integration. Business analysts may be required to play a role of the recipient of information and knowledge, and provider of methodology. Therefore, both business as well as technology competencies are required. In some papers, the discussion on the role of business analyst are undertaken (Table 3). However, there are many interpretations of analyst roles.

Table 2. Publications on requirement elicitation task of business analyst.
Full size table
Table 3. Business analysts’ competencies, roles and involvement in bridging the gaps.
Full size table

Dennis et al. [13] proposed a classification covering business analyst, system analyst, infrastructure and change management analyst, and project manager. Business analyst is assumed to focus on business value creation, but information system modeling should belong to system analyst. The final table covers publications including discussions on challenges formulated for business analysts. In general, information communication technology (ICT) constantly forces business analysts to look for new practices, methods, modelling languages, and tools supporting the modeling process. However, lately, Big Data and data science are strongly impacting business analysts’ activities (Table 4).

Table 4. Publications on business analysts’ challenges.
Full size table

The literature survey was supplemented by additional guidelines and standards review. In BABOK [5], business analyst should focus on understanding enterprise problems and goals, needs and solutions, strategy formulation, change specification, and facilitation of stakeholders’ collaboration. Analysts are assumed to use various types of information, e.g., diagrams, legacy data, user stories, customer feedback, schema, user guides and spreadsheets. Therefore, they are required to understand the user decision-making process and to reduce the uncertainty in requirement elicitation process. They must understand the conditions, environment, and measures, in which the end-user decisions are made. According to Walliser [37], business analysts are to define a plan of action and prepare the processes for deliberation and decision-making. In the deliberation process, they combine cognitive thinking techniques, evaluate options and scenarios in order to form an intentional solution, and choose modelling techniques and software tools.

The CBAP [30] includes a more extended set of business analyst activities. They are responsible for the preparation and validation of feasibility studies, business cases, decision packages, project scope and requirements, and project deliverables [21]. Business analyst is involved in defining the business architecture, covering vision and mission, enterprise policies, procedures, geographical location, and organizational structures. The PMI Guide to Business Analysis [31] emphasizes the information need assessment, requirement traceability, monitoring, and solution evaluation.

BIZBOK [1] is assumed to provide a framework for business architects to address business challenges. This Guide is to include a comprehensive and complete vision of business architecture, combining together various concepts, disciplines, principles, and best practices. Authors of this approach focus on holistic and multidimentional business views, value delivering to stakeholders, the whole business ecosystem presentation, and integration community of individuals and assets. They emphasize constructivism in the activities, however they argue that business transparency is needed to streamline planing and evaluate alternative initiatives. The BIZBOK Guide topics do not refer directly to business analysis issues, but they cover principles that guide practices of architect business solution providing.

3 Business Analyst for Agile Method Driven Requirement Elicitation

Business organizations always have wanted to reduce risk of the current activities and minimize its impact on daily operations. Although workers are directed on what to do and how to do it, they expect a motivation and facilitation instead of management. According to Kuusinen et al. [25], agile methods focus on team collaboration and knowledge sharing. Agile processes employ intensive team work, face-to-face communication and trust as critical factors of working practices. Agility is a way of work grounded in the reality of learning. Research evidence shows that agile methods improve project stakeholders’ communication, facilitate team and organizational cooperation. Business organizations are adopting agile methods, hoping to cope with rapidly changing environments and increase their opportunities for customer satisfaction. As Karvonen et al. [23] mention there is no single definition of business agility, but there is a set of desirable factors that affect the whole organization. Four fundamental values, (i.e., individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contracting negotiation, responding to change over following a plan) are included in agile manifesto. Agile thinking is a holistic enterprise-wide approach that combines together the tools, methods, processes, standards, frameworks of an organization, resulting in a certain comprehensive approach [36]. Such approach includes the best practices and effective deliverables. Agile methods encourage to highly cooperative work between customers and product development teams. They focus on the early and frequent delivery of tangible solutions and in an iterative approach – sufficiently well response to changing customer requirements [15]. Agile methods emphasize the business analyst role and tasks. Business analyst need to understand the philosophy and rationale that underpin the agile approach. Girvan and Paul [15] consider the following business analyst values: collaborative working, self-organizing teams, doing the right thing and the thing right, continuous learning and improvement, planning for change, iterative development, and incremental delivery. Business units are expected to adapt and respond quickly to internal or external pressures. Business analysts are required to contribute to achieving organizational agility by ensuring an adaptability to change. Business analysts can support organizational agility by understanding the strategic context of the business organization, supporting the business architecture blueprinting, lean systems and services thinking implementation, and the investigation of business models and techniques.

The agile project community comprises computerized system users, business owners, stakeholders, sponsors, technical staff, information technology experts, and project managers. Frequent collaboration between the technical and business people is critical to success [10]. The agile project relies on self-organizing and self-managing teams. They apply the best practices and frequent communication to continuously look for feedback from the end users. The business analysts are just in the middle between business representatives and information technology staff. They are searching for the best solutions, which are a certain compromise and the results of deliberation and negotiations. Business analysts should identify issues, which are insuffiently explained or problematic. They must be strongly committed to the frequent delivery of high-quality software product features. Collier [10] considers characteristics of the agile project self-organizing team. He emphasizes people willingness to have control over their work, propensity to be better at what they are doing, and people preference to be part of a social group. These features encourage people to autonomy, self-organizing and self-discipline. People seek methods and techniques to continuously improve their practices and performances. They know they must respect norms and constraints, but they want to be free in what they are doing, because this freedom allows them to be creative. Self-organization requires shared responsibility and mutual support through recommendations and opinions sharing. As Collier [10] perceives, values and working agreements are self-imposed by the agile team members, and they must be consistent with organizational values and guidelines. Working rules are established just by this self-organizing team, so they are not imposed by external stakeholders. The self-organization requires mutual trust, commitments, responsibility, self-control, self-evaluation, and capacity planning.

Unlike traditional methods, agile methods focus on self-management, emergent processes, and informal coordinating mechanisms [6]. Therefore, the business analysts are necessary to facilitate frequent and problem-solving communication. Also Taylor [35] argues that agile methods encourages frequent inspection, communication, adaptation, self-organization, and accountability. The primary benefit of self-organizing teams is that when project participant feel they own the work, they tend to have more passion, time, and energy [26]. Van Oosterhout et al. [40] argue that agility is a way to cope with business organization changes, which are highly uncertain. The business uncertainty relates to the inability to predict the future impact of external forces on business. Beyond that, there are changes, which are quite predictable and the risks can be estimated. However, business organization are looking for people, who are not risk-averse. Business agility is implemented to response to problems and face challenges.

4 Business Analyst in Ontology Driven Requirement Engineering

Requirement engineering is critical stage in the software development life cycle. Communication problems and cultural differences do not facilitate work of developers and stakeholders. Many methods for requirement elicitation and analysis have been proposed to align business needs and information technology solutions. Usage of machine- learning capabilities is a way to solve the problem of business – information technology alignment and support requirement engineering. Business analysts organize deliberation and negotiation sessions, interviewing processes, brainstorming meetings, end user behaviour monitoring. In this way, they learn how end users work and how they communicate with their customers. Usually, beyond these techniques, experts are employed or expert systems are implemented to collect business requirements using various techniques like scenario analysis and simulation, interviews, questionnaire study, and case study analysis. Experts are responsible for domain knowledge collecting and providing it to business and system analysts. For business information system development, business analysts are usually involved in the business process modelling. Domain ontologies as formal representations of domain-specific knowledge are effective tools for process modeling and eliminating the semantic obstacles that unable understanding of specific domains.

Jenz [20] proposed to use business process ontologies to speed up business process implementation by eliminating the semantic gap between business analysts and software developers. Process analysts should rely on the experience of expert system managers to achieve process models with high comprehensibility, also known as pragmatic quality. According to Junior et al. [22], it is a challenge to help the business modelers to consolidate the knowledge in the process modelling guidelines and to reduce the process complexity. Therefore, the correctness of process models can be verified by means of ontologies. An ontology is developed to define process types, properties and relations. Junior et al. [22] argue that it is possible to use an ontology to represent business process model as a meta-model with inference capability to verify another process model’s correctness. The use of ontologies may support the identification of problems that reduce a process model’s comprehensibility. Integration of ontologies with business process modelling has gained attention in recent years, because this approach enriches process data usage and process knowledge reuse at the semantic level. Gurbiz et al. [16] have proposed a process ontology population methodology and tool for an event-driven process chain ontology populating in a fully automated or semi automated (user assisted) manner. The resulting ontologies are evaluated in terms of time-effort and precision metrics.

Yoon [44], using the ontology development method and the Protégé platform, introduced financial fraud ontology and an ontology-oriented financial fraud management system to enable analysts to increase the effectiveness of their work through rich financial fraud ontology knowledge. Cao and Woo [8] presented study focused on an ontological approach for providing domain knowledge to system analysts and designers. System analysts supported the reviewing and selection of components in domain model repository, and generating requirements for a new system.

Ontologies are used for the support of knowledge extraction, but still this approach is not fully utilised. There are proposals of new approaches that emphasize domain ontologies significance for business information development. Gutierrez et al. [17] proposed a novel approach by applying business architecture concepts for the definition of adaptive case management applications in combination with domain-specific ontologies and business rules. Therefore, business domain analysts can use domain- specific ontologies to support specification of goals, activities, and rules. Although business analysts use knowledge acquired from domain experts to develop high-level organizational strategic objectives, their roles in the process of knowledge acquisition and the domain ontologies development is not widely discussed in literature. Researchers rather focus on methodologies instead of business analysts tasks.

5 Case Study on Non-formal Education System Development

In this paper, non-formal education (NFE) is defined as an academic education form for adults. This education is ensured by university community as well as by volunteers from business. NFE facilitates learning by participation in events, e.g., night university visits, open lectures, game competitions, conferences, seminars, summer schools, and company visits. These activities are also known and university social responsibility (USR) events. The USR persuades academicians and students to undertake challenges to solve local community problems, to distribute knowledge and the latest technology solutions within local communities. In NFE community, the win-to-win strategy has significant priority. Local communities learn, but they also provide knowledge, experiences, observations, and opinions to academicians and university students. The complexity of tasks realized by NFE community forces its managers to implement business information systems for administration of different events. Main goal of this case study is to emphasize the role of business analyst in NFE information system development process. Therefore, the NFE architecture is presented in ArchiMate model (Fig. 2), e3 Value model (Fig. 3), and business process in BPMN Bizagi model (Figs. 4, 5, and 6).

There are some criticism that business analyst should focus on business requirements and leave system requirements with system analysts and software engineers [15, 18]. However, the primary role should belong to the business analyst, who understands business goals, determines the information system goals and who should transform business requirements into system requirements. This transformation, known as requirement mapping (Table 5), is extremely important to bridge the gaps between the expectations of business people and preferences of IT specialists.

Fig. 2.
figure 2

NFE system architecture model in ArchiMate language.

Full size image

The requirements mapped in Table 5 are subject of transactions in e3 Value model (Fig. 3). This model enables discussion on communication between information system development stakeholders and visualizes how joint efforts create value of the information system. In this model, exchange of information among analysts and designers allow to create new value of system artefacts. The e3 Value model emphasizes role of the business analyst in comparison with other roles.

Fig. 3.
figure 3

e3 Value model of value exchange among Business Analyst and stakeholders.

Full size image

Traditionally, initial analysis realized for business system development requires process modeling (Fig. 4). Figures 5 and 6 include extended sub-processes for process in Fig. 4. In the process model (see Fig. 4), tasks of business stakeholders, business analyst and system developer are interrelated. The two roles, i.e., Business Analyst and Education Facilitator, who is a domain knowledge expert, should be broken down and played by two persons of different competencies, to reduce risk and ensure high quality of requirement elicitation and system development. As it was presented in literature review, business analyst is expected to bridge the gap between the business requirements as they are specified in ArchiMate language in Fig. 2 and system requirements. The last ones can be specified in SysML or UML language and written in Visual Paradigm or any other computer aided software engineering (CASE) tool, e.g., Modelio, Camunda.

New opportunities of system modeling are created by the application of SysML, because SysML Requirement Diagram is suitable for requirement mapping. SysML requirement specification enables defining requirement attributes, project for requirement implementation, and other SysML diagrams connected with particular requirement diagram. SysML requirements are grouped into three classes, i.e., functional requirements, interface and performance requirements. The last ones define conditions, under which certain functions are performed.

Fig. 4.
figure 4

Process Model of Non-Formal Education Development and Realization.

Full size image
Fig. 5.
figure 5

Sub- Process on Non-Formal Education Requirement Management by Business Analyst.

Full size image
Fig. 6.
figure 6

Sub-Process on Non-Formal Education Strategy Operationalization by Education Facilitator.

Full size image

Just e3 Value model is slightly different in comparison with ArchiMate and SysML models. These models focus on the analysis of system architecture and system requirement. However, the e3 Value model presents communication and transfer of values in this communication. Requirements elicitation and modelling are the key points in system analysis, but e3 Value model supports modelling the system stakeholders’ roles in business information system development project. System requirements modelling belongs to system analysts, who for years have applied UML analytical tools to deal with this task [29].

Modeling languages, i.e., UML or SysML are rather unknown by business users. However, modeling business processes is a way to deliberate by business analysts and end users about sequences of business activities, procedure, routine, and ways of information transfers among business stakeholders. SysML Requirement Diagram is suitable for structuring all system requirements (Fig. 7).

Fig. 7.
figure 7

Structure of Requirements in SysML Requirement Diagram.

Full size image
Table 5. Business into System Requirements’ Mapping.
Full size table

Therefore, the first general view of the whole complexity of requirements can be presented for deliberations with business users. The only problem is that business analyst, system analyst, and business user need a requirement mapping language, technique, and tools for transforming business requirements into system requirements [29]. This transformation is presented in Table 5.

6 Conclusions

In general, two separate groups of conclusions can be presented. Literature review revealed that business analysts’ roles and tasks are known, but authors do not focus on the explanation of what decision processes are realized by these analysts. Bridging the gaps between business needs and system requirements is important, but there is lack of presentations of good practices how to solve this problem. Nowadays, there are many business analysts’ challenges, which result from new information communication technologies, e.g., Big Data, data science, agile methods. The reviewed articles revealed a lack of comparison of software tools used by business analysts.

In this paper, Visual Paradigm is proposed as the best suitable tool for business analysts. Particularly, SysML Requirement Diagram enables the creation of requirement map, in which each requirement can be further precisely described in other SysML and UML diagrams included in one unique project. Finally, the requirement mapping is proposed as necessary to fill the gaps between the needs of business people and the proposals of software engineers. It should be emphasized that Visual Paradigm tool set in its professional version is an integrated software, which includes ArchiMate language and BPMN diagramming possibilities. Unfortunately, the e3 Value modelling is not possible there. The e3 Value model presents the value exchange among the information system project stakeholders. The values are included in communication messages and artefacts exchanged between actors. The values are not quantitatively measured, but just signaled as blue lines (see Fig. 3). The e3 Value model and BPMN diagram present actors, e.g., business analysts and their tasks and roles. The CMMN diagram focuses on actors’ roles and tasks, but this modelling will be a research topic for the future work.