The problem of defining the concept “business analysis in IT project” and scope of business analysis activities are considered. The comparative analysis of three bodies of knowledge on business analysis from leading international institutions International Institute of Business Analysis, Project Management Institute and British Computer Society is performed. The common set of business analysis activities in IT projects is defined and can be used to define the business analysis competence matrix for IT companies.
In today's practice of transformation and optimization of business activity, the leading
role is played by business analysis, as a discipline for identifying business needs and
helping to find the best solution for them. This is borne out by numerous studies in
project management. Thus, according to [
All of the above issues are the result of an improperly organized business analysis process. In part, this phenomenon can be explained by the fact that at the moment the role of business analysts is reduced to solution requirements management, which means actually requirements gathering and determining the compliance of these requirements with the given system and adjusting them if necessary. But in fact, at the moment, the responsibilities of business analysts are much broader. Dissemination of techniques, practices and approaches to performing business analysis in the project activity has led to the need to define the concept and framework of business analysis [3, 4, 5].
This paper deals with the review and comparative analysis of the bodies of knowledge developed by the leading international organizations of the International Institute of Business Analysis (IIBA), the Project Management Institute (PMI) and the British Computer Society (BCS) on the mentioned topics. 2
Complicating the tasks involved in transforming or creating information systems and other solutions to improve business performance has led to expending the list of roles in the project team. A new role “business analyst” has been added to the standard triad “project manager- software engineer – quality assurance specialist”. According to [6], this role is responsible for identifying, analyzing, documenting and verifying project requirements. There are other names for this role: requirements engineer, system analyst, process analyst, enterprise analyst, and others.
Given that this role, unlike the role of project manager recently emerged, questions remain about its area of responsibility, to the list of tasks inherent to business analysis, as well as to the term "business analysis". Defining the answers to these questions will allow us to provide a common understanding of the necessary skills, a list of project and extra-project activities that must be performed by a business analyst to increase the probability of the project success. 3
The problem of defining the term "business analysis" has been addressed in numerous publications. Some authors define business analysis as an extension of the discipline of requirement engineering [4, 7, 8]. The top bodies of knowledge created by international professional institutions are [BABOK, PMI, and BCS]. A number of studies are focused on the study of these professional standards: International Institute for Business Analysis [9, 10] and the British Computer Society [11], and are devoted to analyzing the role and impact of business analysis on the digital economy. The fundamental practical guide on business analysis in terms of software development projects is [6], which contains a list of business analysis tasks and practical recommendations for their implementation. The work [12, 13] is devoted to the study of the interaction between business analysts and project managers.
As a result of research into well-known publications on the problem of determining the area of responsibility of a business analyst, we can draw the following conclusion. The expert environment of business analysts is currently concentrated in three major international organizations: the International Institute for Business Analyst, the Institute for Project Management and the British Computer Society. Each of them has developed a professional standard that defines business analysis, the role of the business analyst and the areas of his responsibility. Thus, comparative analysis of these standards, defining common features and differences is an urgent task, the solution of which will form a unified vision of the role of the business analyst, the limits of his responsibility and may provide a basis for further development of this discipline. 4
According to [14, 15], business analysis is the practice of providing opportunities for change in the context of an enterprise's work by identifying needs and recommending solutions that bring value to stakeholders. Comparing it to the definition in [16], “Business analysis is a set of tasks and techniques used to engage stakeholders to understand the structure, policies, and activities of an organization and to make decisions that enable an organization to achieve its goals,” that IIBA no longer views business analysis as a set of activities and techniques. At present, this term is a generalized representation of the BACCM (Business Analysis Core Concept Model) (Figure 1). According to this model, there are six key concepts that determine the nature of business analysis [14, 15]. • A change is the act of transformation in response to a need. Change works to improve the performance of an enterprise in controlled manner. • A need is a problem or an opportunity to be addressed, which can cause changes by motivating stakeholders to act. • A solution is a specific way of satisfying one or more needs in a context. In most cases a software is a cornerstone of the solution. • A stakeholder is a group or individual with a relationship to the change, the need, or the solution. • A value is the worth, importance, or usefulness of something to a stakeholder within a context. • A context is the circumstances that influence, are influenced by, and provide understanding of the change.
The main idea of this model is an interdependency between concepts: if any of the core concepts experience a change, it should cause us to re-evaluate these core concepts and their relationships to value delivery. BACCM is a conceptual framework, which predefine what business analysis is regardless of domain, methodology and solution nature.
In order to work according to the BACCM, business analyst needs to determine the position of the company and the project by asking questions about each of the core concept such as "what changes dos client want", "what needs have to be covered ", "which solutions can be proposed to make changes", etc." In this way, we get the clearest possible understanding of the current state and minimize the likelihood of missing out on a significant aspect.
PMI defines “business analysis” in the following way [17, 18]: “Business analysis is the application of knowledge, skills, tools, and techniques to: • Determine problems and opportunities; • Identify business needs and recommend viable solutions to meet those needs and support strategic decision making; • Elicit, analyze, specify, communicate, and manage requirements and other product information; • Define benefits and approaches for measuring and realizing value, and analyzing those results.” • Also, in [17], the following short definition of business analysis is formulated: “Business analysis is the set of activities performed to support the delivery of solutions that align to business objectives and provide continuous value to the organization”.
It is easy to see a significant similarity between the definition of “business analysis” in [15] and [17] and, accordingly, the advantage of disclosing this term in BABOK, since understanding business analysis as a strategic practice is broader than a set of techniques and methods, while providing for the needs of stakeholders is a much more accurate reflection of the goals of a business analyst than the value proposition of an organization.
It should be noted that PMI does not introduce the definition of a conceptual model, but based on the definition of business analysis, we can distinguish the following core concepts: • Solutions; • Business goal (analogous to needs from BACCM); • Value; • Stakeholder; • Organization; • Requirement.
The definition of the term "business analysis" [17, 18] does not contain such concepts as "context" and "change". But in the knowledge areas context is studied and "change" is presented as a set of project activities.
BCS defines “business analysis” based on the responsibility of the business analyst: “Business analyst is an internal consultancy role. It has the responsibility for investigating business situations, identifying and evaluating options for improving business systems, defining requirements and ensuring the effective use of information systems in meeting the needs of the business.”[19, 20]. Analyzing this definition, we can distinguish the following key concepts: • Context (business situations); • Need; • Stakeholders (limited to “business”); • Solution (options for improving business systems); • Requirement.
The concepts "value" and "change" are not clearly articulated.
It should be noted that concept “requirement” is not defined as a core concept by IIBA taking into account that requirement is a usable representation of a need, so it is a derived concept.
A significant difference from the first two definitions is that BCS distinguishes a separate role of business analyst in IT. From the BCS perspective, the IT analyst's job is specific and requires additional analytics skills, such as working closely with the development team and a deep dive into system process analysis. Also, an important competence is a basic understanding of the process of development from the software engineer’s point of view in order to be aware of the success of the developers' decisions, the realism and timing of certain tasks. BCS does not insist on such an organization of work, but makes it clear that unless a business analyst is involved in these tasks, someone else must be responsible for understanding the state of development and adjusting the development of the project.
Taking in consideration the above we can conclude that the BACCM model fully reveals the essence of business analysis, defining 6 key concepts that focus on business analytics in the preparation and implementation of business transformation [14].
The definition of the scope and the essence of business analysis can be made based on the list of tasks related to business analysis activities. IIBA in [14, 15] identifies six groups of tasks, which are performed by a business analyst and named by the knowledge area (see Fig. 2):
Depending on the case, the task and the project, the business analyst can get started at any stage, but no stage should be completely omitted. Thus, it should be noted that IIBA does not offer a clear plan of action, but defines a list of activities required for each project.
It is possible to distinguish the basic cycle: Strategy Analysis - Analysis of Requirements and Design Definition - Evaluation of the solution, which corresponds to the three phases of the project: Feasibility study - Project implementation - Evaluation of project results.
Tasks from three other areas of knowledge are completed throughout the project. The methodology of the project implementation can affect the timeframe and intensity of work in each areas, but in a broad sense, the proposed model is implemented for each of them. IIBA emphasizes that the sequence of business analysis tasks in each project may vary.
But usually in the first stage, tasks are performed to determine the current state of the organization, identify business needs or evaluate the effectiveness of the current solution (knowledge areas - Strategy Analysis and Solution Evaluation). In addition, [15] identified five perspectives for business analysis which are used to provide focus to activities and techniques specific to the context of the initiative: • Agile; • Business Intelligence; • Information Technology; • Business Architecture; • Business Process Management.
Perspectives imply a focus on specific context-specific tasks and methods. They are not mutually exclusive; moreover, usually a single project involves multiple perspectives. The main part of modern IT projects combine the perspective “Agile” and “Information technology”. It confirms the suitability of the business analysis task allocation for the specificity of business analyst work in IT projects.
According to [17], business analysis activities are described by the following six areas of knowledge (see in Fig. 3): • Knowledge area “Needs Assessment” describes the tasks that business analysts perform to analyze current business problems or opportunities and to understand what is necessary to attain the desired future state. • Knowledge area “Stakeholder Engagement” contains the task that business analysts perform to identify and analyze those who have an interest in the outcome of the solution to determine how to collaborate and communicate with them. • Knowledge area “Elicitation” covers activities regarding planning and preparing for elicitation, conducting elicitation, and confirming elicitation results to obtain information from sources regarding. • Knowledge area “Analysis” describes the tasks that business analysts perform to examine, break down, synthesize, and clarify information to further understand it, complete it, and improve it. • Knowledge area “Traceability and Monitoring” describe activities regarding tracing, approving, and assessing changes to product information to manage it throughout the business analysis effort. • Knowledge area “Solution Evaluation” describes the tasks that business analysts perform to validate a full solution or a segment of a solution that is about to be or has already been implemented, to determine how well a solution meets the business needs. In general, knowledge areas’ content corresponds to the knowledge areas defined in [15].
PMI, like IIBA, provides a model of ongoing interconnection between the knowledge areas.
This concept is a continuous process of analyzing and identifying requirements that are improved through tracing and monitoring, which can lead to stakeholder engagement and needs identification.
This process creates additional tasks and efforts from the development team and possibly stakeholders, but helps to create the product that will best meet the needs.
BCS, unlike IIBA and PMI, is trying to define a business process model with a defined sequence of steps.
This model is, by its content, a detailed representation of the root cycle "Strategy Analysis" - "Requirements Analysis and Design Definition" - "Solution Evaluation" (Fig. 4).
Separately in [19], a framework of requirements engineering is defined, which is intended to improve the quality of artifacts, which are created by a business analyst (Fig. 5).
The first step is a requirements elicitation, when business analyst gathers information from the stakeholders. Requirements analysis focuses on examining the gathered information in order to identify those that overlap, are in conflict with others or are duplicates.
Requirements validation involves the external stakeholders reviewing the requirements in order to check the quality and validate requirements from the business perspective.
Requirements documentation is concerned with the development of a requirements architecture and requirements management covers the activities needed in order to manage the requirements through the initiatives.
All these tasks are covered by the following knowledge areas from IIBA and PMI standard.
Also, the Business Analysis Maturity Model (BAMM) is defined in [19], which defines the relationship between the boundaries of the decision on which the business analyst works and the level of their influence.
The first level is where the business analysis work is concerned with defining the requirements for an IT system improvement only. The second level is where the analysts work cross functionally on the business processes that give rise to the requirements.
The third level is about improving the business in whole. Thus, this model defines the boundaries of the solution and the context in which the solution will be developed and used.
BCS does not formulate a clear task structure for the business analysis, but it is possible to distinguish the following: • Strategy Analysis; • Business Processes Analysis; • Stakeholder Analysis and management; • Defining the Solution; • Making a business and financial case; • Gathering the requirements; • Documenting and Managing Requirements; • Modelling requirements; • Solution assessment.
It can be concluded that BCS pays more attention to the tasks that the business analyst performs during the pre-project research phase. Comparing the areas of knowledge and based on the tasks that they are composed of, we can formulate the following relationships between business analysis knowledge areas between three bodies of knowledge. The concept “business analysis” is analyzed based on the bodies on knowledge developed by IIBA, PMI, and BCS. The concept definition implies the key role of the business analyst in identifying the business needs, shaping the desired state, and ensuring change through stakeholder collaboration to create the best available solution. IIBA and PMI understand business analysis as a process with clear frameworks, goals and performance criteria for business analysts, and BCS rather defines a list of recommendations for improving the effectiveness of business analysis. The business analysis in IT project can be built based on common framework with limitation on the set of techniques. The professional standards from IIBA and PMI are multilevel bodies of knowledge that contain a more global overall model that defines the set of interconnected business analysis tasks. Each of the IIBA, PMI, and BCS knowledge areas offers a broadly similar approach to the core business analysis areas, emphasizing their importance and versatility. To summarize and bring these areas together to reflect their essence, such items are Business Analysis Planning, Requirement Analysis, Strategy Analysis, Requirement Design and Design Definition, Requirement Lifecycle Management, and Solution Evaluation. The wording of these knowledge areas in the original sources is different, but the overall content is unchanged. Further studies may include examining the list of business analysis tasks, techniques and methods in the realities of IT companies in Ukraine. 2. Sanchez, O., Terlizzi M.: Cost and time project management success factors for information systems development projects. International Journal of Project Management 35.8, 1608-1626 (2017). doi: 10.1016/j.ijproman.2017.09.007 3. Nelson, R.: IT project management: Infamous failures, classic mistakes, and best practices.
MIS Quarterly executive 6.2 (2007). doi: 10.1007/978-3-319-47717-6_1 4. Rubens, J.: Business analysis and requirements engineering: the same, only different? Requirements Engineering, vol. 12.2, 121-123 (2007). doi: 10.1007/s00766-007-0043-3 5. Pastor, O.: A capability-driven development approach for requirements and business process modeling. International Conference on Conceptual Modeling, pp.3-8. Springer, Cham (2016). doi: 10.1007/s00766-007-0043-3 6. Wiegers, K., Beatty, J.: Software requirements. 3nd edn. Microsoft Press, Richmond,
Washington (2013). 7. Aoyama M.: Bridging the requirements engineering and business analysis toward a unified knowledge framework. International Conference on Conceptual Modeling. pp. 149-160.
Springer, Cham. (2016). doi: 10.1007/978-3-319-47717-6_13 8. Sutcliffe A.: Scenario-based requirements engineering (SCRAM). User-Centred Requirements Engineering. pp. 127-147. Springer, London (2002). doi: 10.1007/978-1-4471-02175_6 9. Milani F.: Digital Business Analysis. Springer, Cham (2019). doi: 10.1007/978-3-03005719-0 10. Chernysheva, Y. G., Shepelenko, G. I.: The new profession of “business analyst” and the new occupational standards: the case of Russia. European Research Studies Journal, Volume 21, Special Issue 1. pp. 86-94 (2018). doi: 10.35808/ersj/1161 11. Debra, P.: Defining the role of the business analyst: the business analysis service framework. Diss. University of Reading. Henley Business School, Greenlands, United Kingdom (2018) 12. Tallon, P.: A process-oriented perspective on the alignment of information technology and business strategy. Journal of Management Information Systems. vol. 3, pp. 227-268. (2007) doi:10.2753/mis0742-1222240308 13. Wysocki, K.: The business analyst/Project manager. Hoboken, New Jersey. (2011).
doi:10.1002/9781119200550 14. IIBA (International Institute of Business Analysis): Core Standard A Companion to A
Guide to the Business Analysis Body of Knowledge (BABOK® Guide) Ver 3. (2017) 15. Brennan, K.: A Guide to the Business Analysis Body of Knowledge. 3rd edn. International
Institute of Business Analysis, Toronto, Ontario, Canada. (2015). 16. Brennan, K.: A Guide to the Business Analysis Body of Knowledge. 2nd edn. International
Institute of Business Analysis, Toronto, Ontario, Canada. (2009). 17. PMI (Project Management Institute): The PMI Guide to BUSINESS ANALYSIS. Project
Management Institute, Newtown Square, Pennsylvania (2017). 18. PMI (Project Management Institute): Business Analysis for Practitioners: A Practice
Guide. Project Management Institute, Newtown Square, Pennsylvania (2015). 19. Paul, D., Cadle, J.: Business Analysis. 3rd edn. British Computer Society Learning & Development Ltd, Swindon, United Kingdom (2014). 20. Cadle, J., Paul, D., Turner, P.: Business analysis techniques: 99 essential tools for success. 2nd edn. British Computer Society Learning & Development Ltd, Swindon, United Kingdom (2014).