Elicitation Techniques Used By Business Analysts

Simply put, extraction is the process of discovering requirements. In particular, eliciting often refers to engaging with stakeholders and understanding their needs and expectations regarding the scope and detailed requirements of the project.

There are many requirements extraction techniques.

Many BAs think of large, complex, full-day workshops when they think of elicitation.

In most cases, withdrawals occur in much smaller sessions involving just a few stakeholders.

Hello, this is Laura Brandenburg from Bridging the Gap. Today, I’m going to talk about requirements, extraction techniques used by business analysts. Here are five top-level requirements extraction techniques and a free downloadable checklist to get you started.

When thinking about requirements extraction, most business analysts think of a large, complex, day-long workshop. big event. In reality, requirements extraction is most often done in much smaller sessions, even in techniques that do not involve any stakeholder interaction. However, these small sessions may involve a small number of stakeholders.Let’s step back and talk about what requirements are trigger.

Simply put, extraction is the process of discovering information to compile requirements or to draft and analyze requirements. In particular, eliciting often refers to engaging stakeholders in some way to understand their needs and expectations regarding the scope and detailed requirements of the project.

As mentioned earlier, some techniques do not explicitly involve stakeholder dialogue. I’m going to give you one of my top 5 too.So let’s talk about these 5 requirements trigger technology.

Requirements Extraction Technique #1 – Observation

The first is observation. This is when you sit with the user, or via screen sharing in a virtual environment, watching them do their work or having them demonstrate their work in a virtual way. . We were processing a new account, processing an order, or completing a refund.

Here’s where the user experience circle makes a difference. Stakeholders may not say anything they wouldn’t say in their normal course of business, and they may prefer pure observation where you, the business analyst, don’t ask questions or ask for clarifications. It accomplishes another goal of truly understanding the stakeholder’s complete environment.

As business analysts, we often ask questions. Ask stakeholders what they’re thinking, why they’re doing what they’re doing, their business logic, and ask those questions to really clarify the logic and alternative scenarios. increase. If it seemed to work, what if I clicked something else here, or didn’t receive that document. Start asking questions so that you can grasp the

Requirements Extraction Technique #2 – Diagram Review / Walkthrough

Second requirement trigger A technique I would like to share with you is to do a diagram review or walkthrough. This is also known as prototyping. This is great for pulling out unexpected information, using the structure of the requirements model such as workflow diagrams, use cases, wireframes, entity-relationship diagrams, etc., and using that structure to collectively fill out. That’s the way it was. Models that often surface unexpected information.

You can start with a draft model. For entity-relationship diagrams, you can draw some key concepts on the whiteboard, print them on the sheet, or show them on the shared screen if you’re screen sharing the sheet. If you’re making wireframes, you can create something like a skeleton with some navigation and some parts in place. Alternatively, you can start with a blank page. It depends a lot on the stakeholder group and how proficient they are in using the model. You can also start with a fairly complete draft of the model and work through it to get input and feedback from stakeholders. Various ways to perform walkthroughs and use prototyping techniques with different stakeholder groups.

Requirements Extraction Technique #3 – structured interview

A third technique is called a structured interview. This is the most common technique used by business analysts. Usually a meeting with one person or a small group of stakeholders. It can be a face-to-face meeting or it can be a virtual meeting. You want to have an agenda and be prepared for that kind of meeting.You need a meeting agenda and a requirements checklist. I would like to know what kind of questions you will ask. If you think your stakeholders would benefit from any preparation, you can share it with them in advance. Some stakeholders are much better off if you ask these questions on the fly and don’t overwhelm them with all the questions you may have to ask beforehand.

You can download a sample requirements checklist absolutely free. Check it out as a way to start thinking about what questions to ask in an interview. Of course, that checklist is for a specific kind of requirement, so you need to know what the meeting is trying to accomplish and what questions you need to ask to find the information that will help you reach that goal. I need to clarify.

Requirements Extraction Technique #4 – Documentation review

We promised you one technique that doesn’t involve stakeholder interaction, and that’s the next technique. This is called document review.

It is a requirements extraction technique that can discover a lot of information by analyzing existing documents to understand potential requirements. This saves a lot of time for the involved parties. If stakeholder time and stakeholder access are at a premium, documents that can be reviewed in advance should be prioritized so that they can actually prepare. It helps you come up with questions that you can use for structured interviews and draft diagrams. It also helps to make observations clearer or more specific and specific.

The big caveat with this is that as a business analyst, you don’t want to invest too much in document review and speculation. I don’t want to use potentially dated documents that may not reflect the actual stakeholder point of view just to determine what the requirements are. In many cases, you will need to go back to your stakeholders and validate the information you used or use it to create a requirements checklist. This allows for very productive and structured interviews. question.

Requirements Extraction Technique #5 – survey or questionnaire

Well, the fifth and final technique is a type of stakeholder interaction, which is to conduct a survey or questionnaire. This is a great way to get information from many people or people you don’t have a direct relationship with.

Surveys are also a great way to receive more objective information less frequently. People often write in surveys that they can’t share privately. Conversely, information can be ambiguous and difficult to interpret without context. Bridging The Gap uses surveys to collect feedback from potential customers and obtain feedback after course participants complete the program.

Most BAs use a combination of provocation techniques

I would really like to be proficient in multiple techniques so that I can choose which technique works for a given situation.

Again, if you want to get started quickly, download our free requirements checklist. It is intended for a specific domain or specific area of ​​requirement called customer support. And just thinking about what questions to ask will help you get started quickly. Just reinterpreting it really helps you start to understand what questions to ask. This is where business analysts often get stuck in the first place.

In the comments below, let us know what requirements extraction techniques you use as a business analyst, where you would like to improve, how you find that checklist, and how it has helped you in your business analysis career. We would love to hear from you.

Until next time, this is Laura Brandenburg from Bridging the Gap. We build her analyst profession one business at a time and success starts with you. Thank you for being here.