A common mistake in the development industry is not paying attention to the requirements (functional and non-functional). Requirement elicitation and analysis are the very first step in software development but sometimes, in a bad implementation of agile methodologies, we can lose focus of that and end up building the wrong software.
In an ideal case, you would have someone to talk with users and customers, observe them, and later write down what the business requires. Then, that person would sit down with the technical team to analyze requirements, and business rules, and make a plan for the implementation and validation. But, as I said before that is “ideally” and in countries where software engineering and requirement engineering are still growing as is mine, sometimes you have to elucidate the requirements by yourself, analyze them, and implement them with a very short deadline.
I remember my first job. I was a 19-year-old junior developer in a government organization working in ERP for the financial direction. We were a small team with lots of work, so our manager decided to assign us to different modules and the elicitation of requirements by ourselves; later, we would check out our notes in one of our daily meetings. Initially, I didn’t feel in an ideal situation because of my lack of experience and maybe I wasn’t, but we had to make it work.
I realized pretty soon that elicitation wasn’t as simple as I had thought during my classes in college. We had to deal with the short time of the actors, the ambiguity of the process, the actors with tree view (instead of forest view), and the resistance to change. Again, it wasn’t an ideal situation but we had to make it work.
With time, I realized that rarely we can make an elicitation without troubles and that is ok, because, if the company hadn’t problems they wouldn’t have hired you to build the software in the first place. Through some time doing this kind of work, I have learned some lessons that I will leave you below. Anyway, if you want to go deeper into this topic, I highly recommend you to look at The Guide to the Software Engineering Body of Knowledge (SWEBOK Guide). Said that, let’s go.
Review the same process with more than one actor.
The user or actor usually knows how to do his work, but does not always know how the company works or even what his partner is doing on the desk that is by his side. Actors may ignore what happens with the process after they deliver the record and that’s why you have to listen to the process from the mouths of as many people as you can find.
You may find some power users who know the company pretty well or employees who were there when the process started working in that way. They are pretty helpful and you should pay attention to them, but to find them, you have to talk to several actors and put the ideas together.
People may not be technical, so try to speak his language and don’t try to make him learn yours.
As a noob in the field, I made the mistake of talking technically to the actors. As an analyst, you have to avoid getting too technical about the implementation instead of talking with the actors in terms of the business or even better, in terms the actor can understand easily.
Better communication will get you more clarity. More clarity will lead you to better requirements and that will avoid having extra iterations or sprints because you already are making the right software from the beginning.
Identify priorities.
During elicitation, you will find more than one trouble and probably more problems than what your team can handle at once. This is why you have to identify priorities and talk them down with the owner of the process and with your superior. And that leads us to the next lessons.
Validate your notes with a mentor and/or your superior.
This is probably more for people starting in the area. But even for experienced analysts, elicitation and analysis are more about having the right conversation with the right people than about having a brainstorm with yourself walking in circles in your office.
Receiving another point of view it’s critical when you are trying to make a work with quality.
Now, notice that I’m talking about having not just a superior to check your notes with you, but also a mentor. If you are starting in the area, you may have noticed that there are a lot of things you can learn by yourself but what most people don’t say is that a mentor can save you a lot of headaches. Don’t you have one? Get one.
Identify improvement opportunities.
The user and the client may tell you how they do things from the beginning of the time. They will describe the process they want you to systematize but they may lose improvement opportunities trying to be faithful to their day-to-day.
It’s probably not your work but take into consideration that before making a system for a process, the company needs to optimize the process. You can always take notes and communicate with them. Be proactive.
Remember your objective.
It’s not just building software for the company, it’s solving problems of the company through software, so ask for the problems. Ask the different actors not just what they do and how things should be, but ask them about what kind of things usually go wrong and what happens then.
Respect people. Process owner, user, or client you must respect them.
As we said before, while you are talking with several people you will notice that sometimes actors don’t have a holistic view of the company and its process and because of that, they may ask you for requirements that wouldn’t be right (mostly a matter of security). You will be tempted to make fun of the user and talk about “layer 8 problems”, or maybe of the client with something like “the customers know what they want but not what they need”, which may be true but you must have respect for them. The last thing you want is to have him as an enemy.
Remember that they aren’t supposed to know what you know. If that were the idea you wouldn’t have been hired.
What if people don’t want to collaborate?
Initially, I didn’t want to go into this topic, but while I was reviewing this article with my friend Vanessa, she told me that it would sound too idyllic if I didn’t give any advice about hard people.
There are all kinds of people in this world and there are people that will not collaborate with your elicitation, actors that can even get angry with you doing your work. These people require you to go the extra mile for them and try harder to get their collaboration but remember that you have to do it with sympathy and amiability. I remember that my boss used to buy chocolates for hateful people and most of the time that helped to make them know that you are trying to give a service to the company and the employees.
Of course, if that doesn’t work you will need to scale up the case or look for another person who can help you with that, but try to do that just as the last resource.
Conclusion
Finally, if there is something that I want you to remember, is that during elicitation you shouldn’t fear finding troubles. Actually, you should try to remember that you are looking for the kind of problems that you can fix with software. Situations rarely are as we expected, they are not always ideal and that’s ok.