Analysis Tasks and Skills

Since both business and systems analysis stands on the border between business and IT, it is characteristic of them to require analysts to possess a wide range of skills. It is even more significant in an agile environment, where analysts are expected to manage both roles, as there is no clear split of responsibilities. But also in teams where the roles of BA and SA are strictly separated, the top-notch analysts are aware of the importance of being skilled in both parts of analysis, and they understand that the ability to cover both roles is crucial. The separating line between BA and SA is not sharp, there is always an inevitable overlap. As a result, we present the analysis tasks and skills without separating them as business or systems.

One of the most valuable skills each analyst must have is the ability to analyze and structure information. During a project, it is not only the analyst who learns the domain, who describes the current state of the enterprise, and the problems the solution should solve. Other roles, such as project manager or enterprise architect work with it too, however, only a skilled analyst is able to organize such a big amount of information in a way that is manageable and verifiable.

Main Tasks and Responsibilities

The following section lists what tasks are expected from the analysts along with the qualities which help them achieve these tasks.

1. Identify Business Goals and Key Stakeholders

The main contribution of analysts is they help businesses find solutions to their needs. They design the solution and, in cooperation with the development team, evaluate the solution feasibility. To do that, the analyst must first understand the need and find all important people who might be relevant for the upcoming analysis. Since we are talking about analysis in general, the need in this context could be some business problem or just an IT-related issue. Regardless of the type of need, the key task is to discover the real motivation behind the stakeholders' desires. The analyst must be able to abstract from the low-level requirements and proposed solutions presented by the stakeholders and must first focus on understanding the goals - WHY the stakeholders want the change, together with identifying the constraints and risks associated with it.
The change is usually not driven by a single stakeholder, so before the analysis could start, the analyst needs to identify the key people who could help define the requirements, outline the solution and verify the value it delivered. But the stakeholder is not exclusively someone defining requirements. It is generally anybody with a relationship to the change, so all parties who could be affected by the change or could provide an analyst with relevant information must be recorded too.

Skills and Techniques

Critical Thinking and Problem Solving

Defining a problem to be solved involves ensuring that the nature of the problem is clearly understood. Analysts need to critically consider the needs and try to understand the essence of them. It is often much deeper than it is presented as the stakeholders tend to describe the solution, not the real merit of the problem. In general, analysts should not blindly trust every piece of information he is given, and should always objectively analyze the facts and verify them.

5 Whys

It is a technique that aims to help discover the underlying problem. It is called 5 Whys as it is based on asking "Why?" five times, while each answer forms the basis of the next question. But beware, although it is called 5 Whys, it isn't a good idea to ask "Why?", "Why?", "Why?" like a curious kid unless you want to make stakeholders angry. You don't want to ask "why" directly. You need to be creative and tailor the questions appropriately, so most of the "why" questions should actually start with who, what, when, where, or how.

Industry, Organization and Solution Knowledge

Understanding the business problem is hard without having expertise in the problem domain. How could you analyze the business needs if you don't know the industry in which the organization operates or if you are not familiar with how the organization works? How could you understand the problem the users have with the Customer Management System if you have never worked with it? A lot of analysts try to catch up along the way, but you'd rather make sure to do it in advance. You cannot be an equal partner to business people, somebody they would rely on unless you understand what they say. You need to be trustworthy, prepared, and especially as a business analyst, to be "one of them."

Negotiation and Conflict Resolution

Stakeholders may have different opinions on what they would like to achieve. An analyst must make sure that all goals are articulated and addressed to understand any conflicts between the goals and objectives of different groups of stakeholders. The intent is to maintain and strengthen working relationships among stakeholders and team members. In the end, analyst's responsibility is to make these groups agree on the goals and their priorities.

2. Define Possible Solutions and Select the Best One

As soon as it is clear, what are the goals to be met, the analyst starts to elicit more detailed information which could help identify possible solutions. In the context of solving business needs, the solution might include changes to any organizational component, including processes, systems, or organizational structure or policies. If the analyst is asked to conduct a system change, the solution scope is narrowed down to systems, and the analysis mainly consists of deciding whether to update the legacy system or to implement/buy a new one. The necessary part is also discovering impacts the change is going to have on other components of the organizational IT architecture.

But just defining the need itself is not sufficient for an analyst to come up with possible solutions - it is too general. An analyst needs to discover additional information to have a more concrete idea of the required solution. This process consists of two parts: finding the information (requirements elicitation) and transforming the information into the form, which is clear, concise, and unambiguous (requirements analysis).

The process of uncovering information and using it to find the best solution is not linear. It goes iteratively, meaning that each new information influences the final solution, but demonstrating the solution to stakeholders bring up new requirements and so on.

In the beginning, analysis is focused more on understanding the business goals and on searching for the best change strategy to meet those goals - what organization components need to be changed (IT systems, business processes, or policies, for example). When it is known what components of the organization must be changed, the next phase is to describe the solution components changes in such detail, which enables their implementation.

It could be seen from the above picture, that searching for the best solution is conducted on multiple levels. For example, the analyst is asked to help management to solve the problem of frequent delays in delivering goods to the customers. The analysis has shown that the problem is one inefficient business process that slows everything down. They together decided that the right change strategy is to optimize the process and to start doing the process steps automatically in the system. When it is clear which organization component must be changed, it is time to go one level deeper and begin the solution analysis aiming to describe the implementation details. Will the solution be purchased or implemented in-house? What concrete features does the solution need to have? Are there any technical constraints? What about security? Etc.

Skills and Techniques

Systems Thinking

In the context of systems theory, the system is an organized entity made up of interrelated and interdependent parts. Systems thinking means to have the ability to see the large picture, to look at the solution from the context of the whole organization, and to identify impacts to people, processes, and software that are not necessarily directly changed by the solution.

Problem Solving

Problem solving includes understanding the problem, identifying and considering all alternative solutions, and deciding which solution alternative is the best by measuring them against the objectives and considering their values.

Decision Making

The identified need could mostly be solved by several solutions, so there are usually multiple possible alternatives to consider, each having their advantages and disadvantages. The ability to select the best option from a set of alternatives, along with the ability to document and explain why the decision was made, are very important analytical skills. It includes the ability to present the solution alternatives, to pinpoint the pros and cons, to select the right decision criteria, and to facilitate the whole decision process.

IT Skills

Both business and systems analysts should be knowledgeable in IT, as most of today's solutions involve IT systems. Without understanding the basic IT concepts, IT architecture of the organization, and capabilities of the legacy systems, the analyst could not identify the possible solutions, their impacts, and mainly the technical feasibility, even though just from the high-level.

Organization Knowledge

Not always are mutually agreed decision criteria the main factor that drives decisions in the organization. An analyst should know how the organization accomplishes its goals, what is the organizational structure, who are the influential people, and the relationships that exist within the company, both formal and informal. This can be an indication of what types of solutions the organization has preferred in the past, and what are the constraints and policies, written or unwritten, which may influence the set of solution alternatives. This knowledge can't be gained otherwise than by experiencing the organization for some time.

3. Elicitation

The biggest challenge analysts face is discovering what stakeholders actually need, want, or are required to have or do. To complete this hard task, analysts need to find and aggregate a lot of information from various sources and ensure all parties understand the meaning of the information in the same way. The process is called elicitation.

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

Elicitation is carried out on many levels: on a business level (what are the goals the organization is trying to meet), on the stakeholders level (what particular stakeholders are trying to achieve), and on the solution level (what a particular solution must be capable of). Irrespective of the level, the elicitation looks the same and could be conducted in many different ways: interviews, workshops, focus groups, brainstorming, observation, surveys/questionnaires, reverse engineering of the current systems, studying legacy systems or processes documentation. The analyst should understand the pros and cons of each method and should also be able to combine them to get the best results.

Elicitation is not a one-time activity, it is not an analysis 'phase'. Commonly, elicitation triggers additional elicitation to fill in the gaps or increase understanding. As a result, it is an ongoing activity that starts with the initial need identification and ends once the solution is implemented and evaluated.

The subject of elicitation is any piece of information that could help understand the problem and select, design, and implement the solution to that problem. The information includes mainly the current state of the organization, such as its structure, processes, systems or policies, and the desired future state consisted of the business goals and other types of requirements, ranging from very high-level to technical details.

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

GATHERING VS. ELICITATION

When it comes to discovering requirements, it is very common among analysts to say "gather requirements". However, it is not that simple. Requirements are not lying around on the ground waiting to be picked up. Analysts do not just collect requirements. They need to actively explore, discover, or even create what needs to be solved, how, and when. An analyst is not just a scribe, and instead of gathering, the process could be better described as elicitation.

Analyst's responsibilities are commonly referred to as translating the requirements from the business language to the technical language, serving as a bridge between stakeholders and the development team. Even though this comparison is used very often to illustrate what analysts do, it is very simplified and leads to misinterpretation of what the analyst's actual responsibilities are. Analysts don't just write down stakeholders' desires to hand it over to developers who will implement it. They intensively search for what is needed, they deduce and even develop rather than just accept what they heard.

Skills and Techniques

Facilitation and Elicitation Skills

During elicitation, various people present different ideas and opinions, which may have gotten entirely out of hand and fell over to a free shoot-out of opinions with no meaningful result. To prevent this, the business analyst needs to be able to facilitate interactions between stakeholders, support, and supervise them to ensure the agreement will be reached.

• "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 sometimes confused with simple moderating discussion. But analysts are very often dependent on the information from stakeholders and cannot otherwise continue in work, so it is in their own interest to make the participants decide. So besides moderating interactions, analysts should also be able to clearly articulate what information or agreement is needed and help stakeholders to deliver it by prodding them into creative thinking, keeping the good atmosphere and trying to come up with new ideas or different points of view once the discussion gets stuck without any result. The facilitator's task is to help participants make a decision, solve a problem, exchange ideas and information, or reach an agreement. What is more, different stakeholders may have different interests and opinions, which implies that the discovered requirements could be contradictory. To help stakeholders find the agreement, the analyst needs to have strong Negotiation and Conflict Resolution skills described in the previous section.

Elicitation Tips:

1. Ask Open Question Prodding Into Creative Thinking

If you want people to be creative, don't ask yes/no questions. Always start with what, who, when, why, or how. If you see them stuck, be more creative in asking: ask from different perspectives or ask 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 that there is no information system helping you, how would the process look like?"

2. Ask Stupid Questions

There is only one stupid question, it is the question you did not ask.

If you don't understand something, ask! Even though it is a fundamental thing and you are risking others to look at you amusedly, it is your job to understand it. If you would learn to fly one day, you must first learn to walk. If you don't ask to clarify the basics, you will get lost right in the beginning, and you have failed as an analyst. Your responsibility is not to look smart at all circumstances, but to get the information you need and to understand it. On most projects, you are very 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 get trapped, and don't assume that people know just because they look like they know. Very often, once you ask a stupid question, a couple of people around you will start taking notes because they either did not understand it also, or they just thought they understood, but in fact, they did not.

3. Verify by Repeating

When dealing with a complex or very important information, it is better to verify it even though it seems clear. What works in these cases is to summarize it with your own words and ask stakeholders if you basically say the same thing. If the stakeholder stated: "Each company has only one sales representative" and you really want to be sure whether the relationship is 1:1, you ask: "Do I understand it correctly, that by no means the company has two or more sales representatives? It has never happened and will not happen during the lifetime of the information system?".

4. Ask for an Example

Another technique to verify the information is by asking stakeholders to provide you with an example. This works significantly in case of verifying business process maps, for instance. Checking the general process by trying it out on a real example will give you confidence that the process is correct, and you will also be sometimes surprised that the reality is even more complex than what you have been told.

5. Boomerang Theory

During elicitation, the analyst may uncover information that either came late and will imply rework of existing specifications or came in time but means additional analysis. Some analysts may then tend to sweep the information under the rug to avoid changing what has already been stabilized, hoping that it will be forgotten. However, it is very probable the information will pop up again sooner or later and will hit the analyst like a boomerang in the worst possible time. It is better to solve the problem immediately than hoping it will solve automagically and eventually being struck from the back without warning.

6 Do not overwhelm people during elicitation

Elicitation workshops can sometimes be very intensive, and it is not easy for all participants to remain entirely focused and concentrated during the whole time. To prevent getting wrong information from tired stakeholders, it is a good practice to address only one topic at a time, requiring the elicitation workshop to be divided into logical parts. Such "session" should be kept short and should always end with a clear summary of the outputs and agreements before moving on to another part.

Communication Skills

Communication is an essential analysis skill, which implies that each analyst must be excellent at presenting their thoughts using different communication channels such as face-to-face, conference calls, or emails. Analysts should not feel uncomfortable talking to anybody within the organization, be it an IT person or a senior manager, and must be able to select the most appropriate form of communication according to the audience. For example, experienced analysts avoid using IT jargon when talking to business people, and contrary, they try to learn and use technical vocabulary when talking to the development team to be closer to them.

A crucial part of communication is listening. Listening is not just hearing the words but also understanding their meaning in context. Not everything is said directly, so analysts must read between the lines and connect the dots. An analyst must also be an active listener who assures stakeholders they are heard by maintaining an attentive posture and eye contact, restating and summarizing the key points of what they said, and asking additional questions to encourage them to explain more.

Although the trend is to write less and more meet and collaborate, the analyst will always be more or less communicating in written form. This includes writing emails, creating presentations, or writing documentation. Each written output is required to be grammatically correct, to use the correct words according to the audience, and to have adequate quality corresponding to a professional material.

4. Analyzing Requirements

For bigger solutions, the elicitation activities may result in dozens or even hundreds of requirements specifying the future solution, which are hardly possible to manage if put on one heap without cleaning up. Therefore, the elicitation is followed by synthesizing its results to ensure the requirements are clear, complete, consistent, and unambiguous. This practice is called analyzing requirements. The aim of this practice is to analyze the elicited requirements to ensure that they are clear, understood by all stakeholders, and there are no requirements conflicts. Requirements are decomposed into sufficient detail, structured, organized, validated, and verified. The analysis also involves discovering and documenting relationships among requirements and requirements and supplemented with additional attributes such as author, rationale, priority, or complexity.

Analyzing requirements also has a side effect, which is discovering new requirements. As analysts proceed with cleaning up the elicitation results, the inevitably identify gaps in the requirements and answers to these gaps will eventually generate new requirements:

EXAMPLE

Invoices can't be modified after they were issued.

This is a valid requirement, however, it is far from complete as for the amount of information which is needed for its implementation. What are the exact places (systems, screens, imports) where the editability shall be forbidden? Don't we really need to be able to update invoices by admin, for example? Etc.

The goal of requirements analysis is creating a consistent set of meaningful requirements out of the elicitation results. This involves expressing textual requirements in a way that is unambiguous and understandable to anybody, modeling requirements using diagrams and pictures, or even describing them using mathematical expressions or pseudo-code. Selecting the most appropriate form of capturing requirements depends on many factors, such as who is the target audience (not all stakeholders could read pseudo-code, for example). But no matter the form, the analyst must ensure all requirements meet the necessary attributes such as they are atomic, feasible, testable, concise, and not conflicting with other requirements.

Creating quality requirements is not easy and it takes time before the analyst really masters this skill. Here we at least present several tips which are basic but generally considered helpful:

1. Don't assume
   • Be explicit. Don't use statements such as "It's clear from the context".
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 border 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 anybody space to speculate
   • Don't use "e.g.", "etc.", "all," "none," always list all possibilities

5. Don't take requirements sign-off as proof of understanding

   • Signing off three hundred pages of a system specification is just an alibi and has nothing to do with the real understanding of the solution. Stakeholders can't go through the document, understand it, and verify it.
   • There must be a good relationship between analysts and stakeholders, which is based on mutual understanding and trust. All requirements must be therefore discussed continuously to verify that the solution is exactly as stakeholders want it, and formal sign-offs of detailed specifications should be avoided.

   More information about requirements is included in Part II. It introduces differences between business requirements and software requirements, describes the importance of classifying requirements, shows other ways of modeling requirements than just with text, and also presents tips for creating requirements documentation.

More information about requirements is included in Part II. It introduces differences between business requirements and software requirements, describes the importance of classifying requirements, shows other ways of modeling requirements than just with text and also presents tips for creating requirements documentation.

Skills and Techniques

Modelling and Diagramming

An analyst needs to know different types of models and be able to select the most appropriate one for the given case. Since there is no rule defining when to use which model, analyst always needs to tailor the selection. A more detailed guide of which models to use and is provided in this chapter.

Prototyping

Prototyping shares the same goal with modeling, which is discovering requirements in a more vivid way than just using textual descriptions, but it goes a bit 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 of it, yet it still allows analysts to get really valuable feedback for the solution very early in the project. This helps to finetune the requirements faster and to prevent building something which is not needed.

There are two dimensions of prototypes: 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 of dividing prototypes is by looking at what happens with the prototype after the requirements were identified. The first option is to discard it. This type is called a throwaway prototype. Such a prototype is developed as fast as possible, it is usually built using different technologies than the final product, and the only goal is to get rapid feedback.
The opposite is an evolutionary prototype. This prototype is kept even after the requirements were stabilized, and it is then continuously refined. The common reason for using such a prototype is to validate requirements which are known at the moment and then continue with that as new requirements appear by incrementally extending the prototype.

Requirements Management

Well-modeled, unambiguous and clear requirements may be useless, if they are not organized, their priorities are not set, it is not clear which requirements have already been implemented and what is the process of changing already verified requirements. This is all the responsibility of the requirements management process. Like any other process, requirements management may look differently depending on the environment. Some teams may be managing just requirements placeholders in a spreadsheet backlog, while others may prefer to use sophisticated requirements management software, capturing every tiny requirement in it. There is really not a single best approach, however, the trend is to move closer to agile, more lightweight techniques.

Documenting

Documenting elicitation results is a vital part of requirements management, but the concrete approach depends on many factors, especially on the overall analysis process. More rigid environments prefer to document all requirements before the development starts. Agile processes, on the other hand, specify requirements just in time when they are needed for the actual development, but regardless of the approach, some documentation is needed in all methodologies. The difference is just how much documentation is created and when. The whole topic is rather complex, so a whole chapter is dedicated to this topic.

5. Verify Solution

Analysts guarantee that the solution does things right and that it does the right thing. In other words, after releasing the solution, the analyst needs to make sure the solution is fully functional in production and, more importantly, that it meets the business goals.

What Else Analyst Must be Good at?

The success of any project is half dependent on good relationships between stakeholders and the development team. Analysts serve as an interface between these two entities, so to push the project forward, they must excel in building strong and sincere relationships with stakeholders that are based on mutual trust. Since analysts are in everyday contact with stakeholders, they are the most visible component on the delivery side. As a result, the relationships between analysts and the business determine the perception of the whole development team. This is especially important in hard times. On every project, there are rainy days in which it is more than helpful if stakeholders would turn a blind eye to something that was implemented slightly differently than expected. Software analysis and development is a complex process that requires compromises that could naturally be better negotiated when relationships are functional.

Each stakeholder is different, and while building a good relationship with one is easy, getting on with the other might be a tough task. Dealing with complicated stakeholders requires analysts to have strong interpersonal skills, which enables them to build the best relationships possible. Regardless of who is the counterpart, an analyst must always be professional and nice, appropriately and elegantly dressed, and behave as a partner at any time. They are expected to always be modest, never lie, never sweep important facts under the rug, and to always be helpful. If stakeholders make a mistake, analysts never say it is their fault and that they will have to bear the consequences. Analyst is a partner, who understands the bad things happen and tries to help stakeholders to solve the issue because it still applies "What goes around comes around."

It is also typical of analysis to deal with a big amount of information, follow deadlines, and keep track of all tasks and communication. This requires a solid grasp of organizational skills such as time-management, commitment to deadlines, multitasking, goal setting, and delegating, for example. A very important skill is also issue management.

Although analysts are not project managers, they very often need to be able to cover this role too. There are projects which have a weak project manager, and some small projects do not even have one. It then easily could happen, that it is an analyst who pushes the project forward because the analyst has the right skills, has the closest relationships with the stakeholders and therefore feels the biggest amount of responsibility for the success of the project. To drive the project, the analyst must be a leader with the ability to influence people to move in a particular direction to achieve shared goals and objectives. The art of leadership lies in encouraging various people to collaborate, make decisions, and reach an agreement together.