Level Up your "Requirement Gathering" Game

“Walking on water and developing software from a specification are easy if both are frozen.”

-Edward V. Berard-

---

Since the day I started my career as a business analyst, what amazed me a lot is the thought process we have to put into design solutions. Every business analyst and software engineer knows that struggle is real.

As long as people don’t have a solution at all they are completely okay about it. The moment you bring the “Solution” to the table they will need everything that is not in what you bought. Is it because you failed as a solution designer or fault of people? Well, neither parties are wrong. Human needs and wants are ever evolving and it is harder to satisfy people's needs. The needs will keep on growing and people's minds will change and it is the nature of the people's behaviour. At the same time, as a human, who creates something for humans, it is quite natural and unavoidable to slip or misunderstand requirements of them. But, it is indeed a risk when it comes to business. To make that whole “Requirement Gathering” phase perfect, business analysis emerged. Even though this “BA” who wears this “Magician” hat, sometimes fails at requirements. (What? Why? They are not supposed to fail! Why can't they make the perfect solution?)

Like technology emerges day by day and while giving technological solutions to people, IT industry keeps on looking for this whole “Frequent Changes in Requirement” problem too. Since it is quite natural with human nature, to minimize the risk and the wastage(30-40% of IT projects failed due to inaccurate requirements -PMI) some new concepts have been introduced to industry. Changes to software development life cycle, such as Agile software methodology, prototype methodology and minimum viable products are some of the key concepts examples. Some new job roles such as business analyst, product developers and UX/UI designers have also emerged with the same.

---

“If we play genie and grant client wishes, we are apt to construct castles of code in the air.”

-Larry Constantine-

---

However, as a Business Analyst, I found some ways to level up on this “Requirement Gathering” game. Although I am novice, yes, I learned these from my so far experience, with what I have been through and shared experiences by senior professionals. Your greatest teacher will be your experiences because, even though you learn something you never know the results until you put it into action. Let me share what I have found.

1. Talk to the real end users

Most of the time people who give the requirement are not the people who are going to actually use it. Chances are, you will gather requirements from some senior/middle manager, coordinator or from a product owner but, when you are done with development, do the user acceptance testing and the day of delivering to actual users, you will have to encounter a lot of complaints and grievances. Partially it might be because of operational issues and change resistance but, the larger quota of issues will represent the contradictory needs and inaccurate requirements. So if you are to build a system it is necessary to understand requirements of different user levels. I’m not saying you should only talk to operational users, because in order to understand the business goals and objectives of the system, you should talk to senior managers and middle managers.

When it comes to software products like software as a service, the approach is a bit different. There, you will build a minimum viable product as per the initial requirement and your product will keep on growing with time to time released versions and user feedback upon the releases and issues encountered (Mobile Apps, Social Media Networks etc).

2. Way of gathering requirements

There are so many ways to gather requirements. The way you are going to gather the requirements is important as from whom you are going to gather the requirements. In fact you have to plan the way according to the people you are going to meet. The method you are using for senior managers might not work for operational level workers. As an example, if you are to digitize some day to day operational work you might have to observe the way they conduct the work whereas, to know the business objective of the system you might do an interview or questionnaire. However, before you start the requirement gathering, it is essential to plan it properly. To plan effectively you should have a good understanding about the users too.

3. Everybody loves pictures

“... with proper design, the features come cheaply. This approach is arduous, but continues to succeed.”

-Dennis Ritchie-

Another important task after gathering requirements is, documenting it. Documenting doesn’t necessarily mean you have to write it down on multiple pages. People are less in to go through lengthy documents. The solution is, to represent it graphically. This is a tricky part because again you have to be mindful about which graphical representation should share with which user. In business analysis we often use UML diagrams and wireframes/mockups to graphically represent the requirements. But, although developper understands data flow diagrams and class diagrams, your client might not. In the same way although the senior management understands the flow diagram and state diagram, operational users will not.

Apart from the diagrams, one of the most effective method is using mockups/wireframes. Wireframe design can be understood by any user regardless of their knowledge or level. Also it is a great way to set up basic expectations about the UI/UX experience they are going to have. There are so many open source wireframe/mockup designing tools. Even now google draw.io and visual paradigm is facilitating it for some extent. My favourite tool is the pencil project.

4. It’s common sense

This is another pitfall we easily fell into, common sense. Although that “sense” is called “common”, actually it is not common to you and me and everybody else. The level of common sense of a tech savvy millennial and their parents are different when it comes to use of software. If we talk about domain specific knowledge or job specific knowledge, what common sense to them is not common sense for us. I have come across with so many real life situations on how this common sense gap will hit you. Therefore it is really important to tackle these unrevealed requirements simply because it is common sense. Not only when gathering requirements, when you are documenting and communicating them to stakeholders and the development team you should clearly mention everything and set the expectations without assuming anything, because chances are your level of commonsense to the technology and what the developer team commonly know can be different.

These are the main things I have experienced and learned in my day to day Business Analyst life. The way of applying these and using the tools and techniques may vary with the nature of the work you are carrying out. However, I hope I have helped you out with, already known but always keep missing practices in requirement gathering and elicitation. I would love to hear your experiences also if you are a member of an IT product development team or as a Business Analyst. Do share your experience and what you do to tackle requirements.