Analysis Tasks and Skills

Since both business and systems analysis sit at the intersection of business and IT, analysts in these roles must possess a wide range of skills. This is even more critical in an agile environment, where analysts are often expected to manage both roles interchangeably due to the lack of a rigid split in responsibilities. Even in teams where the BA and SA roles are strictly separated, top-tier analysts recognize the importance of being proficient in both domains, understanding that the ability to bridge both roles is essential. Because the dividing line between business and systems analysis is never sharp and an overlap is inevitable, we present the following tasks and skills as a unified set for the modern analyst.

One of the most valuable skills any analyst must possess is the ability to analyze and structure information. Throughout a project, many roles—such as project managers or enterprise architects—interact with the business domain and identify problems. However, it is the skilled analyst who is uniquely equipped to organize this vast amount of information into a format that is both manageable and verifiable.

Main Tasks and Responsibilities

The following section outlines the core tasks expected of analysts, along with the specific qualities and skills that enable them to execute these responsibilities effectively.

1. Identify Business Goals and Key Stakeholders

The primary contribution of analysts is their ability to help businesses find effective solutions to their needs. They design the solution and, in collaboration with the development team, evaluate its technical feasibility. To achieve this, the analyst must first thoroughly understand the underlying need and identify all key individuals relevant to the upcoming analysis. In a general analytical context, this "need" could range from a strategic business problem to a specific IT-related issue. Regardless of the nature of the requirement, the core task is to uncover the true motivation behind the stakeholders' requests. The analyst must be able to abstract from low-level requirements or premature solutions presented by stakeholders and focus initially on understanding the objectives—the "WHY" behind the change—while identifying associated constraints and risks.

Since change is rarely driven by a single individual, the analyst must identify the key stakeholders who will help define requirements, outline the solution, and verify the value it delivers. However, a stakeholder is not exclusively someone who defines requirements. More broadly, it is anyone with a relationship to the project; therefore, any party affected by the change or capable of providing relevant information must be identified and recorded.

Skills and Techniques

Critical Thinking and Problem Solving

Defining a problem to be solved requires ensuring that the nature of the issue is clearly understood. Analysts must think critically about stated needs to grasp their true essence. The root cause is often much deeper than initially presented, as stakeholders tend to describe a desired solution rather than the actual merit of the underlying problem. Consequently, analysts should not blindly accept every piece of information they receive; instead, they must objectively analyze facts and verify them through independent validation.

The 5 Whys Technique

This technique is designed to uncover the root cause of a problem by iteratively exploring cause-and-effect relationships. While the name suggests asking "Why?" five times—with each answer forming the basis of the next inquiry—practitioners should exercise caution. Repeatedly asking "Why?" directly can come across as interrogation or mimic a curious child, potentially frustrating stakeholders. To be effective, an analyst must be creative and tailor their questions; many "why" inquiries are more effectively phrased using "who," "what," "when," "where," or "how" to elicit deeper context without creating defensiveness.

Industry, Organization and Solution Knowledge

Understanding a business problem is nearly impossible without expertise in the relevant domain. It is difficult to analyze business needs without a deep understanding of the industry in which the organization operates or a clear grasp of its internal mechanics. Similarly, one cannot truly understand the challenges users face with a Customer Management System (CRM) without prior experience with such platforms. While many analysts attempt to "learn on the fly," it is far more effective to build this knowledge in advance. To be viewed as an equal partner—someone stakeholders can truly rely on—you must speak their language. To be trustworthy and prepared, an analyst must strive to be perceived as "one of them."

Negotiation and Conflict Resolution

Stakeholders often hold diverging views on project objectives. An analyst must ensure that all goals are clearly articulated and addressed to identify any underlying conflicts between the interests of different stakeholder groups. The objective is to maintain and strengthen professional relationships among stakeholders and team members alike. Ultimately, it is the analyst's responsibility to facilitate consensus, ensuring all parties agree on the final goals and their respective priorities.

2. Identify Solution Alternatives

Once the objectives are clearly defined, the analyst begins eliciting detailed information to identify potential solutions. In the context of addressing business needs, a solution may involve modifications to any organizational component, such as processes, systems, organizational structures, or policies. If the task is specifically a system change, the scope narrows to IT systems; the analysis then primarily involves evaluating whether to update the legacy system or to implement or purchase a new one. A critical part of this phase is also identifying the impact the proposed change will have on other components of the organizational IT architecture.

However, defining the need alone is insufficient for an analyst to propose viable solutions—it is simply too broad. The analyst must gather additional information to form a concrete vision of the required solution. This process consists of two distinct stages: gathering information (requirements elicitation) and transforming that information into a format that is clear, concise, and unambiguous (requirements analysis).

The process of uncovering information and leveraging it to find the optimal solution is non-linear and highly iterative. Each piece of new information influences the final outcome; conversely, demonstrating a potential solution to stakeholders often triggers the discovery of new requirements. This feedback loop continues until the solution is fully refined.

Initially, the analysis focuses on understanding business goals and identifying the most effective change strategy to meet those objectives—determining which organizational components (such as IT systems, business processes, or policies) require modification. Once the necessary changes are identified, the focus shifts to describing these solution components in sufficient detail to enable their successful implementation.

As illustrated in the previous diagram, the search for the optimal solution occurs across multiple levels. For instance, an analyst might be tasked with helping management address frequent delays in customer deliveries. In this scenario, the analysis reveals that the root cause is a single, inefficient business process that bottlenecks operations. Together, the stakeholders and the analyst determine that the most effective change strategy is to optimize this process and automate its steps within the system. Once the specific organizational components to be modified are identified, the focus shifts one level deeper. This next stage of solution analysis aims to define implementation details: Will the solution be purchased as a third-party product or developed in-house? What specific features must it include? Are there any technical constraints or security requirements to consider?

Skills and Techniques

Systems Thinking

Within the framework of systems theory, a system is an organized entity composed of interrelated and interdependent parts. Systems thinking is the ability to maintain a holistic view—seeing the "big picture"—by analyzing a solution within the context of the entire organization. This involves identifying ripple effects on people, processes, and software that might not be directly modified by the solution but are nonetheless affected by its implementation.

Problem Solving

Problem solving encompasses a comprehensive understanding of the core issue, identifying and evaluating various alternative solutions, and determining the optimal path forward. This is achieved by measuring each alternative against defined objectives and assessing the value each option delivers to the organization.

Decision Making

Most identified needs can be addressed through several different approaches, each with its own set of advantages and disadvantages. The ability to select the optimal option from a set of alternatives, while documenting and justifying the rationale behind that choice, is a critical analytical skill. This involves effectively presenting alternatives, pinpointing pros and cons, defining the right decision criteria, and facilitating the entire decision-making process among stakeholders.

IT Skills

Both business and systems analysts must be technologically proficient, as the vast majority of modern solutions are centered around IT systems. Without a solid grasp of fundamental IT concepts, the organization’s specific IT architecture, and the capabilities of legacy systems, an analyst cannot accurately identify potential solutions, assess their impacts, or evaluate technical feasibility—even at a high level.

Organization Knowledge

Mutually agreed-upon decision criteria are not always the sole factor driving organizational choices. A skilled analyst must understand how the organization achieves its goals, its formal hierarchy, and the influential individuals and informal networks that exist within the company. This institutional knowledge provides insight into historical solution preferences and highlights unwritten constraints or policies that may shape the range of viable alternatives. Such expertise is rarely documented and can generally only be acquired through direct experience within the organization over time.

3. Elicitation

The most significant challenge analysts face is uncovering what stakeholders truly need, want, or are required to achieve. To navigate this complex task, analysts must gather and synthesize vast amounts of information from diverse sources while ensuring all parties reach a shared understanding of its meaning. This process is known as elicitation elicitation.

Elicitation: Iterative derivation and extraction of information from stakeholders or other sources. (source: BABOK)

Elicitation occurs across multiple levels: the business level (identifying organizational goals), the stakeholder level (understanding individual objectives), and the solution level (defining specific system capabilities). Regardless of the level, the underlying process remains consistent and can be conducted through various techniques, including interviews, workshops, focus groups, brainstorming sessions, observations, and surveys. It may also involve the reverse engineering of existing systems or the thorough study of legacy documentation. A skilled analyst must understand the advantages and limitations of each method and know how to combine them to achieve the most comprehensive results.

Elicitation is not a static "phase" or a one-time event; rather, it is a continuous, iterative activity. Elicitation often uncovers gaps or raises new questions that trigger further inquiry to deepen understanding. Consequently, it remains an ongoing process that begins with the initial identification of a need and only concludes once the solution has been fully implemented and evaluated.

The scope of elicitation encompasses any information that aids in understanding the problem or in selecting, designing, and implementing an appropriate solution. This primarily includes data regarding the current state of the organization—such as its structure, processes, existing systems, and policies—as well as the desired future state. The latter consists of business goals and various requirements, spanning from high-level strategic visions to granular technical specifications.

In terms of analysis, the most common form of elicitation is the discovery of requirements.

GATHERING VS. ELICITATION

Within the industry, the phrase "gathering requirements" is frequently used, yet it oversimplifies the reality of the role. Requirements are not static objects waiting to be collected; they are often hidden, contradictory, or yet to be defined. Analysts do not merely act as scribes; they must actively explore, discover, and sometimes even facilitate the creation of what needs to be solved. Because this requires proactive engagement and synthesis rather than passive collection, the process is more accurately described as elicitation.

The role of an analyst is often described as "translating" business requirements into technical language, acting as a bridge between stakeholders and the development team. While this metaphor is frequently used to illustrate the function of the role, it is an oversimplification that can lead to a misunderstanding of an analyst's true responsibilities. Analysts do not merely act as passive conduits, recording stakeholder desires to be handed off for implementation. Instead, they are proactive investigators who intensively explore needs, deduce implications, and actively shape the final solution rather than simply accepting information at face value.

Skills and Techniques

Facilitation and Elicitation Skills

During the elicitation process, stakeholders often present a wide array of competing ideas and opinions. Without proper guidance, these sessions can easily devolve into unproductive debates or a "free shoot-out" of conflicting views that yields no meaningful results. To prevent this, an analyst must act as a skilled facilitator—managing interactions, mediating disputes, and providing the necessary structure to ensure the group remains focused. The analyst's goal is to supervise the dialogue effectively, guiding stakeholders toward a shared consensus and a concrete agreement.

• "Facilitation is the skill of moderating discussions within a group in order to enable all participants to effectively articulate their views on a topic under discussion, and to ensure that participants in the discussion are able to recognize and appreciate the differing points of view that are articulated."*
  (source: BABOK)

Facilitation is often mistaken for mere discussion moderation. However, analysts are frequently dependent on stakeholder input to progress; therefore, it is in their own interest to drive participants toward a decision. Beyond simply moderating interactions, an analyst must clearly articulate the specific information or agreement required. They must actively assist stakeholders in reaching these goals by stimulating creative thinking, maintaining a positive atmosphere, and introducing fresh perspectives or alternative viewpoints when discussions stall. The facilitator’s primary objective is to empower participants to make decisions, solve problems, exchange vital information, and reach consensus. Furthermore, because stakeholders often have diverging interests, requirements may emerge as contradictory. To resolve these discrepancies, the analyst must leverage the robust Negotiation and Conflict Resolution skills detailed in the previous section.

Elicitation Tips:

1. Ask Open Question Prodding Into Creative Thinking

If you want people to be creative, avoid asking yes/no questions. Always start with what, who, when, why, or how. If you see them getting stuck, be more creative in your questioning: ask from different perspectives or pose unusual questions.

Examples:

• "What do you mean by that? Can you explain it in other words?"
• "How would you solve this if you could design it from scratch?"
• "Imagine there is no information system to help you; what would the process look like then?"

2. Ask Stupid Questions

The only stupid question is the one you didn't ask.

If you don’t understand something, ask! Even though it is a fundamental rule and you risk having others look at you with amusement, it is your job to understand. If you want to fly one day, you must first learn to walk. If you don’t ask to clarify the basics, you will get lost right at the beginning—and as an analyst, you will have failed.

Your responsibility is not to look smart under all circumstances, but to get the information you need and to truly understand it. On most projects, you are likely to look like a "good-for-nothing" at first, but over time you will become an expert and the most valuable member of the team.

Also, don't fall into the trap of assuming people know something just because they look like they do. Very often, once you ask a "stupid" question, you'll see several people around you start taking notes—either because they didn't understand it either, or they only thought they did, but in fact, they didn't.

3. Verify by Repeating

When dealing with complex or critical information, it is always better to verify it, even if it seems clear. A technique that works well is to summarize the information in your own words and ask the stakeholders if you are both on the same page.

For example, if a stakeholder states: "Each company has only one sales representative," and you want to be certain whether the relationship is strictly 1:1, you might ask: "Do I understand correctly that a company can never have two or more sales representatives? It has never happened in the past, and we don't expect it to happen during the lifetime of this system?"

4. Ask for an Example

Another effective technique for verifying information is to ask stakeholders for a concrete example. This is particularly useful when validating business process maps. By walking through a general process using a real-world scenario, you gain confidence that the model is accurate. Often, you will be surprised to find that reality is even more complex than the high-level descriptions you were originally given.

5. Boomerang Theory

During elicitation, an analyst may uncover information that either arrives too late—necessitating the rework of existing specifications—or arrives just in time but requires additional analysis. Some analysts might be tempted to "sweep this information under the rug" to avoid modifying what has already been stabilized, hoping it will simply be forgotten.

However, it is highly probable that this information will resurface sooner or later, hitting the analyst like a boomerang at the worst possible moment. It is always better to address a problem immediately rather than hoping it will solve itself "automagically," only to be struck from behind without warning later on.

6. Do Not Overwhelm People During Elicitation

Elicitation workshops can be very intense, and it is not easy for all participants to remain focused and concentrated the entire time. To prevent gathering incorrect information from exhausted stakeholders, it is a good practice to address only one topic at a time. This requires dividing the workshop into logical segments. Each session should be kept short and should always end with a clear summary of the outputs and agreements before moving on to the next part.

Communication Skills

Communication is an essential analytical skill, meaning that every analyst must excel at presenting their thoughts through various channels, such as face-to-face meetings, conference calls, or emails. Analysts should be comfortable speaking with anyone in the organization, from IT specialists to senior managers, and must be able to select the most appropriate form of communication for their audience. For example, experienced analysts avoid IT jargon when speaking with business stakeholders; conversely, they adopt technical vocabulary when engaging with the development team to build rapport and technical alignment.

A crucial part of communication is listening. Listening is not just hearing words, but understanding their meaning within a specific context. Not everything is stated directly, so analysts must "read between the lines" and connect the dots. An analyst must be an active listener who ensures stakeholders feel heard by maintaining an attentive posture and eye contact, restating and summarizing key points, and asking follow-up questions to encourage further explanation.

Although the current trend leans toward "writing less and collaborating more," analysts will always communicate extensively in written form. This includes drafting emails, creating presentations, and writing documentation. Every written output must be grammatically correct, use terminology appropriate for the audience, and maintain the high quality expected of professional materials.

4. Analyzing Requirements

For larger solutions, elicitation activities can result in dozens or even hundreds of requirements. It is nearly impossible to manage such a volume if they are simply "put in one heap" without a proper cleanup. Therefore, elicitation must be followed by a synthesis of the results to ensure that all requirements are clear, complete, consistent, and unambiguous. This practice is called Analyzing Requirements.

The aim of this process is to examine the elicited requirements to ensure they are understood by all stakeholders and that no conflicts exist. Requirements are decomposed into sufficient detail, then structured, organized, validated, and verified. This analysis also involves discovering and documenting relationships between individual requirements and supplementing them with additional attributes, such as author, rationale, priority, or complexity.

Analyzing requirements also has a vital side effect: the discovery of new requirements. As analysts proceed with refining the elicitation results, they inevitably identify gaps. Finding the answers to these gaps will eventually generate new, more refined requirements.

EXAMPLE

Invoices cannot be modified once they have been issued.

While this is a valid requirement, it is far from complete in terms of the information needed for implementation. The analyst must dig deeper:

What are the exact locations (systems, screens, API imports) where editing must be restricted? Is there truly no exception, such as an administrator needing to perform corrections under specific conditions? How should the system handle attempts to modify an issued invoice—should the fields be grayed out, or should an error message be displayed?

The goal of requirements analysis is to transform elicitation results into a consistent set of meaningful requirements. This involves expressing textual requirements in a way that is unambiguous and understandable to everyone—whether through modeling with diagrams and pictures, or by using mathematical expressions and pseudo-code.

Selecting the most appropriate format depends on several factors, particularly the target audience (for example, not all stakeholders can read pseudo-code). Regardless of the form, an analyst must ensure all requirements meet essential quality criteria: they must be atomic, feasible, testable, concise, and non-conflicting.

Creating high-quality requirements is challenging and requires time to master. Below, we present several fundamental tips that are generally considered helpful for any analyst:

1. Don't assume
   • Be explicit. Avoid phrases like "it's clear from the context." If something is important, state it clearly to leave no room for doubt.
2. Be strict about blind spots
   • Fill in all blind spots as soon as possible. It is easier to do it now while you have access to the stakeholders and while you remember all the details.
3. Be strict about edge cases and exceptions
   • Always ask "What if...?": "What if this fails?", "What if we don't manage to do it in time?", etc.
4. Be concrete and accurate
   • Don't give anyone room to speculate.
   • Don't use "e.g.", "etc.", "all," or "none"; always list all possibilities explicitly.
5. Don't take requirements sign-off as proof of understanding
   • Signing off three hundred pages of a system specification is often just an alibi and has nothing to do with a real understanding of the solution. Stakeholders cannot realistically go through such a document, understand it, and verify it.
   • There must be a good relationship between analysts and stakeholders based on mutual understanding and trust. All requirements should therefore be discussed continuously to verify that the solution is exactly what stakeholders want, and formal sign-offs of detailed specifications should be avoided.

More information about requirements is included in Part II. It introduces the differences between business requirements and software requirements, describes the importance of classifying them, and explores various ways of modeling requirements beyond simple text. It also provides practical tips for creating comprehensive requirements documentation.

Skills and Techniques

Modelling and Diagramming

An analyst needs to be familiar with different types of models and be able to select the most appropriate one for any given case. Since there are no hard rules defining which model to use and when, an analyst must always tailor the selection to the specific situation. A more detailed guide on selecting and using various models is provided in this chapter.

Prototyping

Prototyping shares the same goal as modeling: discovering requirements in a more vivid way than through textual descriptions alone. However, prototyping goes a step further. Analysts use prototypes to validate requirements by letting stakeholders actually try the solution out. A prototype typically does not cover all the features of the final solution—it simulates only specific parts—yet it still allows analysts to gather invaluable feedback very early in the project. This helps to fine-tune requirements faster and prevents building features that are not truly needed.

Prototypes can be categorized into two dimensions: horizontal and vertical.

Horizontal prototypes provide a broad view of an entire system or subsystem, focusing on user interaction more than low-level system functionality, such as database access. Horizontal prototypes are useful for:

• Confirmation of user interface requirements and system scope
• Demonstration version of the system to obtain buy-in from the business
• Develop preliminary estimates of development time, cost and effort

source: Wikipedia

A vertical prototype is an enhanced complete elaboration of a single subsystem or function. It is useful for obtaining detailed requirements for a given function, with the following benefits:

• Refinement database design
• Obtain information on data volumes and system interface needs, for network sizing and performance engineering
• Clarify complex requirements by drilling down to actual system functionality

source: Wikipedia

Another way to categorize prototypes is by what happens to them once the requirements have been identified. The first option is a throwaway prototype. This type is developed as quickly as possible, often using different technologies than the final product, with the sole goal of gathering rapid feedback. Once its purpose is served, it is discarded.

The opposite approach is an evolutionary prototype. This prototype is retained even after the requirements have been stabilized and is then continuously refined. The primary reason for using this approach is to validate known requirements and then incrementally extend the prototype as new requirements appear.

Requirements Management

Well-modeled, unambiguous, and clear requirements may still prove useless if they are not properly organized, if their priorities are not set, or if it is unclear which have already been implemented. Furthermore, a defined process for handling changes to verified requirements is essential. All of this falls under the responsibility of the requirements management process.

Like any other process, requirements management can look different depending on the environment. Some teams may manage only requirement placeholders in a spreadsheet backlog, while others prefer sophisticated requirements management software to capture every minor detail. There is truly no "one-size-fits-all" approach; however, the prevailing trend is moving toward more agile, lightweight techniques.

Documenting

Documenting elicitation results is a vital part of requirements management, but the specific approach depends on many factors—most notably the overall analysis process. Rigid environments often require all requirements to be fully documented before development begins. In contrast, agile processes favor "just-in-time" specifications, where requirements are detailed only when needed for actual development. Regardless of the methodology, some level of documentation is always necessary; the difference lies solely in the volume and the timing of its creation. Because this is a complex subject, an entire chapter is dedicated to exploring it in detail.

5. Verify Solution

Analysts ensure that the solution does things right and that it does the right thing. In other words, after the solution is released, the analyst must confirm that it is fully functional in production and—more importantly—that it effectively meets the original business goals.

What Else Must an Analyst Be Good At?

The success of any project is halfway dependent on the relationship between stakeholders and the development team. Analysts serve as the interface between these two entities; to push a project forward, they must excel at building strong and sincere relationships based on mutual trust. Since analysts are in daily contact with stakeholders, they are the most visible component of the delivery side. Consequently, the relationship between the analyst and the business determines the perception of the entire development team. This is especially critical during difficult periods. Every project has its "rainy days," where it is more than helpful if stakeholders are willing to turn a blind eye to minor discrepancies. Software analysis and development is a complex process requiring compromises that are naturally easier to negotiate when relationships are functional.

Each stakeholder is different; while building a relationship with one may be easy, getting along with another can be a challenge. Dealing with difficult stakeholders requires an analyst to have strong interpersonal skills. Regardless of the counterpart, an analyst must always remain professional, approachable, and appropriately dressed, behaving as a partner at all times. They are expected to be modest, honest, and helpful—never "sweeping important facts under the rug." If stakeholders make a mistake, a good analyst never assigns blame or leaves them to bear the consequences alone. An analyst is a partner who understands that mistakes happen and works to help stakeholders resolve the issue, remembering that "what goes around, comes around."

Analysis also involves managing vast amounts of information, meeting deadlines, and tracking tasks and communications. This requires a solid grasp of organizational skills, such as time management, multitasking, goal setting, and delegation. Another vital skill is proactive issue management.

Finally, although analysts are not project managers, they often need to step into this role. On projects with weak management—or none at all—it is frequently the analyst who pushes the project forward. Because the analyst has the closest ties to the stakeholders, they often feel the greatest responsibility for the project's success. To drive a project, an analyst must be a leader with the ability to influence people, guiding them toward shared goals. The art of leadership lies in encouraging diverse individuals to collaborate, make decisions, and reach agreements together.