If you’re like many business analysts out there, that last one may seem nearly impossible, but once you learn these three techniques that apply to both [waterfall and agile] methods, a more lucrative and less stressful career is exactly where you’re headed.

1. Effective communication,
2. Excellent requirements elicitation, and
3. Excellent documentation of requirements

If you’re ever asked how to handle a difficult stakeholder, how would you answer that in an interview? I’m about to show you with these three techniques.
The first is knowing how to effectively communicate. The second is how to elicit requirements, and third is how to complete the documentation process that will make interviewers know you’re the person for the job.

Effective communication, when it comes to how you express your skills, there are few make or break factors that determine your success, so here is a gold mine of communication information.

1. The first is “You should” or “You must”. Even though you know the right action steps, people dislike being advised with this phrase. With dictative language like that, your stakeholders are going to feel threatened.
2. The next would be “You’ll never”. We use this nearly every day in our speech with phrases such as “I’ll never get this done,” or “I’ll never understand this.” When you turn this phrase into second person you language, it makes the listener feel as if you’re putting limits on their abilities.
3. Next is “Why don’t you?” These three words sound aggressive. This language comes up when you’re explaining an alternate path. Instead, use something such as “Have you ever considered,” or “You could try” instead of using that “Why don’t you” and then telling them to do something different.
4. “You never” or “You always”. When you begin a sentence with “You,” it’s important to be careful with what words come next. Using this phrase intimates that you know everything about the person, which is never the case.
5. The next one is “You’re wrong”. Hey, even if you know for a fact that the person is wrong, it’s best never to tell them that. But you’d be amazed at the problems that arise just because of those two words, so watch your language. Never use that phrase “You’re wrong.”

Now that you’ve learned the phrases to avoid in your communication as a business analyst, let’s move on to requirement elicitation. To help you master requirement elicitation, I’ll provide you with a preliminary conversation checklist that ensures your success.

1. Ask the right questions to get more specific details on the requirements. In doing so, you allow yourself to become clearer on the project. The fact is that you’re the one with the most important parts of the process, and when you ask questions, you lift the fog off your own path.
2. Take notes while still staying engaged in the conversation. Note taking serves as the ultimate act of active listening. Instead of nodding your head and repeating “Uh huh” and “Yes,” write down what the speaker communicates to ensure that you don’t miss any important details. That’s going to help keep you focused on what they’re saying.
3. Repeat back what was heard to ensure correct understanding of what the person is stating. In my two decades on the job, I can confidently say that repeating your understanding is the most proactive measure you can take. This strategy ensures that everyone understands what is expected and that you’ve taken the time to give your full attention and understand what that person was saying.
4. Keep the meeting on point and everyone engaged in the conversation. Friendly chit chat can be effective sometimes. Everyone loves a little water cooler talk, but the truth is that the business analyst world is fast-paced. When you keep the communication on target, it doesn’t waste time. But make sure that every person engages with the conversation. If not, unexpected obstacles may occur as you complete your work.
5. And the last strategy to making your career take off is documenting requirements. The most valuable skill I’ve learned in requirements documentation is really to separate each requirement into its own category. Are you ready to know what those categories are?

The first is obviously business requirements documentation of requirements. Right?

1. The business requirements focus on daily activities, rules, and interactions that are required in order to complete the overall business process.
2. The second is functional requirements. The functional requirements are coming from areas where you’re determining now what it’s going to look like to implement these business requirements. So when we take into consideration that we’re putting these business requirements into some sort of automated process, most likely a software application, then we’re starting – with the functional requirements, we’re starting to take that software into mind and start creating that process of how that’s going to look within the software.
3. And the third is technical requirements. This last requirement area has to do with how technology supports those business requirements and functional requirements. Anything from hardware descriptions, security requirements, things like that are going to go into this category.

These three strategies are just part of what it takes to master business analysis with both waterfall and agile methods. I wish I had known about these years before. If I had, I wouldn’t have struggles to gain footing in this industry. But now that I do know, I made a choice to give business analysts in all stages of their career a chance to bypass all the struggle and put themselves on the straight trajectory to the income they want, the respect they want, and the high-paying clients they want.