Elicitation Questions for Business Analysis Information

By Kadir Çamoğlu

"The right questions to the right person, in the right place, at the right time…"

One of the most important prerequisites for a successful IT software project and the right software solution is to conduct an effective business analysis. Good business analysis is only possible with the right questions. I wrote the "What Should You Ask? Eliciting Requirements for Software Solutions" as a supportive reference for conducting successful business analysis studies. The book covers the entire process of business analysis, with over 2000 sample questions in four categories comprising application lifecycle management, business analysis process, product, and non-functional dimensions. It also includes over 300 samples of business analysis information, 25 checklists, and 22 exercises not only for the analysts at the beginning of their careers but also for the experienced ones.

What you'll learn:

• 5 Ws + How
• Asking Questions
• The 4 Dimensions of Business Analysis
• Application Lifecycle Management Dimension
• Pre-Project Works
• New Solution Development
• Existing Solution Implementation
• Software Maintenance
• Analyzing Current State and Business Needs
• Defining Future State, Business Value, and Gap Analysis
• Dealing with Uncertainty
• Stakeholders
• Transition
• Business Analysis Process Dimension
• Planning
• Elicitation
• Business Analysis Information Management
• Collaboration
• Requirements Analysis and Conceptual Design Definition
• Scope and Change Management
• Business Analysis Process Improvement
• Product Dimension
• User - User Role
• Functional Requirements and Functionality
• User Interface
• Business Objects and Data Structure
• Reporting and Data Analytics
• Non-Functional Requirements Dimension
• Functional Suitability
• Performance Efficiency
• Compatibility
• Usability
• Reliability
• Security
• Maintainability
• Portability

 

Who should read this book?
The primary audience for this book is anyone who performs analysis tasks in software solutions, regardless of what the business card says. The following audiences will benefit most from this book:

• Analysts
• Systems Analysts
• Systems Engineers
• Business Analysts
• Requirements Engineers
• Process Analysts
• Web Designers
• User Experience Designers
• Developers
• Test Experts
• Project Manager
• Demand Managers
• Service Managers
• Consultants
• Solution Developers
• Product Managers
• Scrum Masters

 

Apart from those, other positions such as key users, operational support staff, and process owners in business units, can also benefit from this book if they are to contribute to software solutions. Although the book is primarily written for beginners in business analysis, experienced analysts will also benefit from it, as it offers different perspectives.

What this book is not:

It is not a book about any particular industry (finance, manufacturing, retail, etc.). Besides that, this book comprises sample questions that the analyst can use in the business analysis process. It does not contain questions to prepare for certification of business analysis.

• Language: English
• Publisher: Kadir Çamoğlu
• Release date: Sep 8, 2022
• ISBN: 9798215124994

Kadir Çamoğlu

Kadir Çamoğlu (Ph.D., Computer Engineering), is a problem solver, consultant, teacher, author,  practitioner, and architect of system and software solutions. Over the past 25 years, he has worked in every phase of the software development life-cycle. Kadir, who has been particularly focused on software quality and processes for the last 10 years, has published 13 books in Turkish in print and electronic formats in this field. He also holds the CBAP, PMP, PSM I, CSM and CSPO certifications. [e-mail]

Book preview

CHAPTER 1 - Analysis with Questions

A new change request comes in, and you get to work. It may be a completely new solution or a request to update existing software. Your supervisor assigns you the task. Maybe there are a few pages of documents to go with it... or just a simple email...

−  So where do you start now?

−  Who owns the company, who is the client?

−  What kind of software will you be developing? What is required?

−  What is your budget and deadline?

−  Who will be on your project team, who will you be working with?

−  Will you be working in an agile or traditional way?

−  What level of documentation will you undertake?

Analysis, in its simplest definition, means understanding or trying to understand. People listen, observe, read, and ask questions to understand. They ask themselves questions, questions of others. They receive answers and ask questions to clarify if they have understood something.

A good analysis comes from asking the right questions to the right people at the right time. That is exactly what this book is for: To help you ask the right questions.

I have been in the software industry for over 25 years. I have worked as an analyst, tester, developer, and project manager on software projects. and project manager on software projects. By the way, I have worked as an academic at college for about 4 years. I have worked in consulting companies. I have given many courses. Along the way, especially friends who were just starting their careers have asked me the following question repeatedly: But how do we know what to ask at the beginning of the job? Is not there a list of questions, a guide? The first seed for this book was sown when I first heard this question. In my courses and consultations, I not only explained the issues but also discussed the questions that could be asked. I may have also created and passed around lists of questions that related to the title of the courses or consultation I was giving. Nevertheless, none of this was comprehensive enough to cover the entire business analysis process.

Therefore, you will find direct questions on many topics without explanation. However, to speak a common language, I briefly explain some important concepts in the Key Concepts chapter at the end of this part. In the following sections, I also discuss interviewing, which is our major work in interacting with stakeholders. Finally, we conclude the part by discussing the concept of question a bit.

CHAPTER 2 - Key Concepts

The main purpose of this chapter is to identify some concepts in order to establish a common basis of communication between you and me. The following concepts are the most basic business analysis concepts covered in this book. Of course, there is much more to this book than what I have explained here, but I hope this explanation is sufficient for us to understand each other.

Change:

IT Infrastructure Library (ITIL) defines infrastructure change as the addition, modification, or removal of an approved, planned, or supported service or service component that may affect IT services. IIBA-BABOK uses the simpler phrase transformational action in response to a need, for change.

A change is made to improve the performance of the company. Developing a new product or service for this purpose, improving an existing solution, or fixing its flaws are generally accepted as changes.

Requirements:

Requirements are one of the most important elements of the business analysis process. We can define them in very general terms as:

The situation or capability that a stakeholder (including the regulator, so also documents such as contracts, specifications, standards) requires solving a particular problem or achieve a particular purpose.

−  A requirement is a specification of what needs to be improved.

−  They are statements of how the system should behave.

−  A requirement is what we will have when the project is complete.

−  A requirement is something the product must do or the quality it must have.

––––––––

Business Analysis Information:

An analyst does not just work on requirements. She/he also works on risks, assumptions, constraints, business rules, uncertainty, dependencies, stakeholder concerns, stakeholder information, and other similar information about the project and solution. All of this information, including the requirements, is referred to as the business analysis information.

Requirements Classification:

We can classify requirements from two different perspectives:

−  Levels

−  Types

The requirement levels are business requirements, stakeholder requirements, and solution requirements. The business requirements level refers to the highest level and includes very general requirements, i.e., business statements related to the project. You try to detail these requirements throughout the analysis. In this phase, you work with many stakeholders. We define the requirements you receive from these stakeholders as stakeholder requirements. However, we cannot pass the stakeholder-level requirements directly to the developers. They first need to be elaborated, put into shape, and freed from their shortcomings or problems. After these investigations, the solution requirements emerge. The solution-level requirements refer to the most detailed requirements level which can be coded.

We can list the requirement types:

−  Product Requirements (Functional / Non-functional)

−  Project requirements

−  Quality requirements

−  Transition requirements

Product:

The result of an operational process or project is called a product. If the product is incomplete, it is called an intermediate product; if it is functionally complete, it is called a final product. A product can be tangible (e.g., a car, a computer, a cell phone, software) or intangible, such as an organizational structure, a process, or a service.

Products are introduced as part of a solution. Thus, they exist to meet a business need and create commercial value.

In the definitions and explanations above, we have understood what the product is. Here, the software that is created because of a software project, is also considered a product. However, most times, the industry thinks of packaged solutions that are used by more than one customer when talking about a product. Solutions that are developed only for a specific company or customer are called customized solutions.

Solution:

A solution is what eliminates a business problem or achieves a business goal. Sometimes this thing can be a single piece of software, sometimes it can include over one piece of software and additionally other process elements such as training, installation, and restructuring.

The solution is that which meets business requirements, satisfies stakeholder expectations, and creates expected value. The solution may be a simple process or product change, or it may be a new component, service, product, or product line.

For example, a change in legislation may require that some personnel information be stored in the database in encrypted form as part of the Personal Data Protection Act. In this case, a simple update of the company's HR software will suffice. When this update is performed, the solution is also implemented.

Let us assume that your organization wants to radically change its production tools and processes. Here, you face a huge program such as analyzing the existing processes, designing new processes, developing software to support these processes, integrating this software, and transferring the current processes and information to the new system. In such a case, the solution comprises one or more programs and their results.

Project:

Projects are temporary activities undertaken to find a solution to a business need. Examples of projects may include activities such as developing a new product, enhancing an existing product, revamping the company's organizational structure, or conducting market research.

Business Needs:

The Business need is the reason that triggers the software project. Strategic goals, operational problems, or an opportunity in the marketplace can be defined as a business need. We can also consider business needs as high-level requirements.

As an example of a business need, we can cite a software product that can be used to handle the customer relationships of an entity operating in the service sector. Here, software that can be accessed from both mobile devices and personal computers can be considered a high-level business need and requirement.

Another example of a business need is managing the work advances and expenses of a large staff working in many locations.

Stakeholders:

A stakeholder is anyone who is affected by or influences the project. On the one hand, stakeholders are the most important sources of analytical information for us; on the other hand, they are people who must be satisfied by meeting their expectations of commercial benefits. The vast majority of stakeholders have an expectation of the solution to be revealed, and this expectation must be best understood and managed.

Business Value:

Commercial companies seek first to maintain their existence and then to increase their profitability and market share. They set strategic goals, try to reduce their running costs, and increase their profitability. In this context, the projects undertaken to solve an operational problem or seize a market opportunity must create commercial value for the institution. This commercial value is essentially based on three factors:

−  Fulfillment of a legal obligation and avoidance of penalties

−  Tangible gains

−  Intangible gains

We can give examples of tangible gains, such as increasing profits, reducing costs, or increasing market share. Intangible gains are elements such as social responsibility, increasing brand awareness and prestige of the company.

Context:

All kinds of conditions that affect the change, are affected by the change, and allow us to better understand the change are called context. Change occurs in a specific context and understanding that context has a great impact on the success of the change and the project.

So, what is this context?

The context can be the attitudes, beliefs, and demographics of the stakeholders, or it can be internal, such as the culture, goals, and business style of the company. It can also be external, such as competitors, laws, and the economy. Apart from these two, conditions that we cannot define as internal or external, such as season and location, are also considered as context.

Let us proceed by making the issue more concrete. Say you are working on a mobile software project that you will develop with internal resources. Now, consider: Does it affect the project whether the team assigned to the project has experience in mobile development? Of course, it does. But as an analyst, you cannot address this under the heading of need or analysis. But if you want to be a great analyst, you need to see this situation in context and act accordingly.

Let us continue with another example. Can you work in the same way when the stakeholders of a project are scattered in different countries and have only one location? No, of course you cannot. Your analysis efforts, timing, and calendar planning will always be different. Time zone differences, even country, culture, and language differences, may come into play.

Analysis will look different in a company with a more formal, correspondence-based culture than in a company that is more flexible, candid, and whose communications are oral. Also, working with stakeholders who have already done an IT project and working with stakeholders who are doing an IT project for the first time will affect your analysis effort and process.

As you can see, these examples can be expanded. You may come across something here that we never thought of. So, should you contextualize everything concrete and abstract around us and act on it? No, of course not.

––––––––

It is also an important analysis task to determine the internal and external conditions that will impact the project, product, analysis, change, and related work. Here is a list of things that you should be sure to consider and evaluate. Query each of these items for the project in question. If you think they might pose a risk, dig into them a bit more and decide whether you want to contextualize the information and impressions you gain.

−  The most basic contextual conditions an analyst should consider might be:

−  The standards of the company for change

−  The written and unwritten business culture of the company

−  Regulation

−  Seasonal influences

−  Locations and physical distribution of stakeholders

−  Stakeholders' project experience in IT

−  Project team experience

−  Project budget and capabilities

−  Maturity of the process

−  Maturity of the technology

−  The company's software processes

CHAPTER 3 - Elicitation

Elicitation work means receiving, collecting, and getting information from stakeholders or other sources of need. This is the most basic and important method for identifying requirements.

Elicitation work can be planned or unplanned. For example, you may identify needs by conducting planned needs workshops or focus group work with specific stakeholders. Or you may meet with a stakeholder and during the conversation, some requirements may emerge. As a good analyst, prepare for both situations and use them as needed.

Determining the elicitation approach and planning the work is done in the phase where the analysis is planned. In this phase, information obtained about the stakeholders and other sources of requirements is used to determine which stakeholder and issue to work with and which requirements gathering techniques to use. In the later phases of the analysis, the approaches to the associated activities are reviewed and updated as necessary as the elicitation work approach.

After you clarify the elicitation approach, make the necessary preparations. This phase includes work such as informing relevant stakeholders for the study, allocating and preparing the necessary resources.

When the preparations are completed and the time is right, you carry the elicitation activity out. In this phase, activities such as ensuring stakeholder participation and involvement in the study, adherence to the scope of the study and fulfillment of its purpose and note-taking on the issues discussed are conducted.

After the study, the analyst records the information obtained in writing based on his notes. He checks the prepared document in terms of content and form and gets it ready to be sent for confirmation.

After the elicitation work, the written analysis information is sent to the stakeholders who took part in the corresponding study and if there is any suggestion for correction, you will receive their confirmation.

After stakeholder feedback, any necessary corrections are made, and finally, the newly obtained analysis information is shared with other stakeholders.

––––––––

Be mindful of the following when gathering business analysis information:

−  Constantly question what the change is that you are in and how it is occurring during analysis information acquisition activities. (By chance, we mean the change that will occur in the company).

−  Since the process of elicitation is iterative in nature, the level of understanding required will increase as the studies progress. Therefore, do not be under the illusion that you have a very clear understanding of the need from the beginning. Focus on clarification and revisit it as the work progresses.

−  Try to understand the solution components needed throughout the analysis and elicitation process.

−  Seek to understand the relative value of the information you get in your studies and seek stakeholder opinion on that value.

−  Track all internal and external factors that could affect the solution and project and see if there are any changes to your current determinations.

Determining the Elicitation Approach

Determining the elicitation approach is the stage of determining what techniques we will use in elicitation, how stakeholder participation will be ensured, what activities will be undertaken, and in what order. Determining the elicitation approach should begin in the planning phase of the analysis. As the timing of elicitation comes, it is useful to review the approach and revise it if necessary.

By establishing an effective approach, you can make better use of stakeholders' time and better ensure their participation in the project. This will make your analysis activities more successful and on schedule. This will further increase the likelihood of successful product delivery.

To identify approaches to requirements gathering, consider the following topics:

−  What analysis information should be obtained? (Requirements, process flows, business rules, screen prototypes, etc.).

−  From whom or where can you obtain the information you seek? (Domain expert, end user, sponsor, etc.)

−  How can you obtain information from relevant sources? (Personal interviews, workshops, observations, etc.)

−  When should you do the work? (Your availability, stakeholder's availability, resources for the meeting, etc.)

One of the most important elements of an effective analytical approach to knowledge gathering is that you do not take unnecessary time away from stakeholders. Seeing that your work is effective and appropriate will have a positive impact on the support and time stakeholders will give you.

In conclusion, it is important to consider the entire analysis process, the stakeholders, the project, and the product as a whole when planning your approach to gaining analysis knowledge. Plan by trying to see the big picture before moving on to the detailed work.

Preparing for Elicitation Work

Preparing elicitation work involves organizing the necessary resources, planning calendars, preparing the materials, and informing people. The goal of any elicitation work is to ensure that the activity to be conducted is most efficient for everyone involved, especially you.

During the preparation phase, consider:

−  The purpose and scope of the particular study should be clarified. (The requirements of module X will be detailed, or the first drafts of the mobile software screen prototypes will be defined, etc.

−  It should be clarified what technology or techniques will be used in the study. (Although the techniques to be used in the design have been established, they may be revised at this stage if deemed necessary.)

−  It should be determined who the participants will be. (Perhaps new stakeholders have joined the project or some of the existing stakeholders are not available.)

−  Materials to be used in the meeting should be prepared. (Projection, flipchart, white-board, camera, etc.).

−  Participants should be reminded of. (Format, location, date, time of the meeting, what is expected of participants in each work, etc.)

−  You should send the work agenda and relevant documents to participants.

−  If possible, the questions to be asked of participants should be determined in advance.

−  Depending on the agenda, a schedule for the activity should be prepared.

Performing Elicitation Work

Elicitation work is the activity of obtaining, discovering, and disclosing analytical information from various sources using conflicting techniques.

The work takes place in 3 main phases:

−  Introduction

−  Main part

−  Conclusion

The introduction explains the purpose and format of the study. If the participants do not know each other, the phase of getting to know each other is conducted. The methods and rules of the study are explained, and questions are answered.

The work planned in the main part is carried out according to the agenda and schedule. Missing points are explained with questions.

In the last part, the work done in the session is summarized. Missing work and open questions are clarified, and tasks are distributed. If anything remains to be done after the work is completed, it is identified and explained.

Activities to obtain analysis information can basically be done in 3 different ways:

−  Activities conducted by working with stakeholders: For example, one-on-one meetings, requirements workshops, activities such as brainstorming. In this type of work, the analyst meets with the stakeholders involved in the project and obtains the requirements from them or develops them together.

−  Elicitation takes the form of research: This is the systematic sourcing of information from various materials for information that cannot be obtained from stakeholders. For example, process documents, information got through data mining, examination of help desk records...

−  Elicitation through trial and error or experimentation: These are activities that are not known to stakeholders, are not found in other sources, and are based on investigations such as observation and field research.

––––––––

In the elicitation activity, the analyst is the facilitator of studies and acts as a moderator. The points that the analyst should pay attention to and fulfill during the study are:

−  Make sure participants are comfortable. If you have an unhappy stakeholder or are in uncomfortable conditions, move the location or correct the situation.

−  Make sure the work is proceeding according to the agenda and plan. If there are deviations from the plan, fix the extended conversations, expedite the work, or take other necessary action.

−  Make sure the analysis information obtained is at the level of detail you are seeking. If they are not detailed enough, ask additional questions.

−  Make sure the work stays within the scope established for the event. If there is any situation that causes a deviation from scope, intervene, and say that you will address the out-of-scope issues in other studies and that you will return the reporting.

You can conduct elicitation work using certain techniques. When conducting these studies, activities are organized and carried out using one or more techniques. The most common techniques that can be used in studies are:

−  Questionnaire

−  Interface analysis

−  Brainstorming

−  Personal interview

−  Workshop

−  Analysis of documents

−  Observation

−  Analysis of business rules

−  Conceptual modelling

−  Studies with focus groups

−  Creative activities based on gamification

−  Market analysis

−  Prototyping

−  Process analysis

−  Data mining

−  Modelling of data

––––––––

Your elicitation activities using these techniques will examine the following information:

−  Notifications

−  States and transitions

−  Business rules

−  Work tasks and data structures

−  Functional requirements

−  Dysfunctional requirements

−  Acceptance conditions

−  Constraints

−  User interfaces

−  Messages

−  Reports

−  Risks

−  Roles, authorities, and permissions

−  Processes

−  Drafts

−  Assumptions

Besides the above analysis information that you receive when performing elicitation activities, it may be necessary to determine some attributes. For example, if you are working on a large project, if you have many stakeholders, and if more than one analyst is performing the analysis, information such as who received the analysis information, from whom, and at what time, becomes important. Such information about the analysis information is called attributes. The most commonly used attributes are:

−  Source of the analysis information

−  Who receives the information?

−  When received?

−  Number of information

−  Importance of the information

−  Maturity of knowledge

−  Difficulty and complexity of the information

−  Status of the information (approved, confirmation received, etc.)

––––––––

Documenting the Results of Elicitation Work

Although information obtained from analysis collection studies is kept as meeting notes during the study, it should subsequently be documented in a format preferred by the company and shared with relevant stakeholders. It is the analyst's responsibility to document the results of the requirements gathering studies.

The interview notes taken at this stage may be in written form or in a variety of media, such as audio recordings, video recordings, photos of the work on the white-board, or video conference recordings.

In documenting the studies, sometimes the information obtained is incorporated directly into the analysis or design documents, and sometimes it may take the form of interim documents.

Validating Business Analysis Information

It is useful to obtain verbal and/or written confirmation during and after eliciting the analysis information.

After the work of elicitation, you must communicate the results of the study that you have written to the stakeholders involved in the study and obtain their consent. If there are any, ask them to return the missing or incorrect information to you or to confirm that they accept it.

It is important to obtain written confirmation. However, it is even more essential to get verbal confirmation of the study. Can you imagine dozens of requirements and other business rules that you will build on a business rule that you will misunderstand at the beginning of a two-hour study? Worse, you would have completed the analysis without realizing it, and passed that analysis on to the development team. At the end, in the user acceptance testing phase, you would face a stakeholder looking at you in wonder.

In software projects, an effective testing process can detect and fix the bugs in the developed software after a good analysis. However, it is not possible for the testing team to find a bug made during the analysis. This is because the test team performs the tests based on the requirements in the analysis document. The best way to find an error in the analysis is to conduct verification with the stakeholders as often as possible, both