Requirement Gathering for Software Projects
One of my most challenging tasks as a Business Analyst or Product Owner was always the requirement gathering and the building of project documentation. What is the right way to do it? Is there any secret recipe?
There is no such thing as right way! & There is no recipe!
Each project will demand you to find a way that works in your company routine and business aspects. But there is some tools that I used in some of my projects and will share with you in this article.
Knowing the people involved
First of all… Before start making documents, spreadsheets and creating tasks, get to know all the people that will work directly and indirectly with you and your team, and define which is the role of each one of them on the project.
If you don’t know the roles and who may help you, ask for the managers involved in the project to assign one person to each subject that the project could need.
Believe me, it looks like something that can be done later, but later the absence of these information can give you a massive headache.
Interviews
Meet the people that will interact with the product/feature and understand what are the expectations and the main issues, is very important.
And after the interviews is nice to have a meeting with the people responsible of each department to make sure that the requirements that were extracted from the interviews are correct and suitable to the project strategy.
The interview can be done in two ways:
- While doing a work in process observation
If you choose to observe the work process that will be affected by the new product/feature to understand their functionality, you will need main topics to understand it, like: 1. Is there any system that interact with the process? 2. Is there any information that is provided by database? and so on…
In this kind of “interview” the majority of questions will arise organically, during the observation, but is very important to prepare the main topics to make sure that the initial questions to develop a initial product vision will be answered.
It’s important as well to talk with more than one person about the same process, to make sure that all aspects are taken into consideration.
I personally, like to create a process map (flow chart) of how the process is done and highlight decision points and bottlenecks that must be focused on.
This type of interview is very handy in projects that will automate a process that currently is done manually
- Structured interview
This kind of interview is basically previously schedule and with all the questions defined. Usually take place in a neutral location (e.g meeting room) and have a estimate duration. Another way of doing this kind of interview is through digital forms (e.g google forms, typeform, etc),
It‘s important to have all the questions needed to develop the initial product vision and understanding of the project goals. Some examples of question that you can ask are:
- In your opinion what’s the biggest problem with this process?
- What’s the amount of time that you spend to do this task?
- How many emails from clients do you get daily about this functionality?
- If you could chance something, what would it be and how?
Make sure that the questions are leading the person to tell you what are the problems that he/she faces everyday and to collect some ideas…
It’s important as well to talk or get the digital form from more than one person, to make sure that all aspects are taken into consideration.
This type of interview is very handy in projects that you need to understand the needs of and department or persona to develop a solution.
Design Sprint
A design sprint is a time-constrained, five-phase process that uses design thinking with the aim of reducing the risk when bringing a new product, service or a feature to the market.
To know more about I highly recommend you to read the book Sprint: How To Solve Big Problems and Test New Ideas in Just Five Days By Jake Knapp, John Zeratsky, Braden Kowitz
I am a huge fan of design sprints because it give you the opportunity to understand the project goal, brainstorming, research some benchmark, select some ideas, experiment them and receive customer feedback to validate them or not. All of it in five days!
And the nicest thing for me, beside all these that I said above, in a design sprint you must put together in the room people from all the involved departments and backgrounds (e.g customer support agents, developers, ux/ui designers, CEOs, etc), so the product/feature created could be the result of everybody’s work.
Create a shared document
For me, one of the most helpful tools after the design sprint or interviews sessions is the document where I put all the requirements that I took note, in this moment, often I discover a question that I forgot to ask or an aspect of the usability that I didn’t consider.
So in that moment I share the document with the person that can give me and answer and ask he/she through a comment. I used to do that with Google docs or Confluence or Asana.
It’s important to use a software that everybody have access, so you can keep record of the changes.
Use visual aids
Some projects, in my experience, most of them, can produce an enormous amount of data and documents and make really hard to understand the purpose of the project. That’s when the visual aids can be your savior.
A flow chart or a mind map showing the project’s main points and/or ideas can be a watershed when it comes to make yourself be understood.
Some tools that I used and recommend are: draw io, Bizagi modeler,Visio — Microsoft and Real time board.
Embrace the change
Changes will happen, no matter how good your project documentation is, something may change and there is no need to be angry or sad, it’s part of the life and we need to deal with it.
So, when some requirement change or be added to your project, make sure that everyone involved is aware of it and its consequences (if alter deadline or resources needed) and that the development team understand the new data.
That’s all folks!
Some of my lessons learned in my past experiences that I hope can help you in your projects.
See you ;)
