Careful with the language and the ego

Have you ever been annoyed at a dinner party with a lot of friends from some other profession (say Lawyers, Sport Broadcasts, Musicians, Physicians or any other), when they just assume you understand their terms of know what the hell they mean? Well, don't do that to others! Have this in mind, especially if you are the Analyst in charge of gathering requirements in a Software Project.

Let’s face it, most people don't have a clue what requirement elicitation is. It's even less probable they know what a use case is, or understand what a business rule is for you. But if they don't understand you, and because of that the requirements come out wrong, it’s your fault. And I really mean it!

You can't go asking "give me the business rules" or "what type of data is this? varchar 100?". Your mission, since you accepted it with the job, is to learn their terms, their language, and then translate that into software engineering dialect so your development team can build it.

In a requirement elicitation meeting, the star is your business expert, not you. The one with the sole truth is him/her because it’s his/her problem you are trying to understand and solve. Don´t call use cases use cases if you know it confuses your user. Call them screens, forms or whatever they call it. Don’t refer to the fields in the form, ask for what other little boxes you need. Don´t ask how many concurrent users will there be, ask how many people works in the system at the same time.

So far, we have solved the language thing. Let’s go to the ego part of this post. If you are like me, cocky because you know you are really smart, well... remember that part of being smart is being able to adapt and behave according to the situation. (If you are not cocky, but humble, well good for you, but still remember to behave in a smart way).

In a requirements meeting, it’s very tempting to come up with a really new and smart way of doing things. But, the truth is you don’t know your client business that much, and you don´t know the organization or all the regulations. Maybe your way is really cool, but there is a very good chance it’s not appropriate for the specific need. For example, people don’t like change, and if you want to force a thousand employees to change the way they do simple tasks in the information system that works just fine because you want to show how smart you are, well, that might not be the best ways to go.

Remember to listen, ask properly, make sure you really understood, and remember that the Analyst role can decide if a software project fails or succeeds.