Collecting software requirements. Real life story
I would like to share my experience of collecting the requirements for four projects. Despite my first project being unsuccessful it taught me a lot about creating digital products. In the majority of cases when founders are collecting software requirements they often rely on their own conclusions rather than deeply researching their potential market.
I am going to use this article to show you the mistakes I made, so you can avoid them!
How did I collect my product requirements?
When creating my first product I was creating a solution for a problem that only existed in my own mind. I had not done the necessary research to ensure that this wonderful idea actually had a market wanting to buy it. Due to the lack of research I undertook, I would not even count this experience when discussing the collection of product requirements.
I approached my second product more responsibly, having already received the primary requirements from industry experts. Using the internet to collate necessary research I tried to determine who would need this solution. I discovered that my potential customers were representatives of the automotive industry.
For my next product, I went a step further, by first finding the demand for my product before working on its realization. Determining who the client was first, allowed me to sign a preliminary contract on this basis so that I could develop the business.
The following two products had already been made to a high standard. I had started with the validation of an idea followed by a deep competitive analysis that identified all the potential advantages as well as issues. I also studied statistics and necessary materials on the industry and entered into a dialogue with 100 people who fell into my target audience. An MVP was then developed to test out the hypotheses I had formed. What is MVP?
Why do you need software requirements?
The biggest mistake
The need for collecting proper requirements became apparent immediately after the first one and a half to two months of working on my first product. I realised when you do not yet have a full understanding of what your product should do, you cannot effectively explain it to your target audience.
This was the biggest mistake I made when developing my product. I also found that when the requirements are not fully detailed this often leads to issues with budgeting and timing.
Preventing a lack of data
So you are looking for an investor for your business, you have a great idea, you understand who needs it and have studied all the statistics as well as having analysed all similar solutions currently on the market. The investor agrees that you have a great idea and is ready to invest but do you know how much investment you will need? How long you will need to complete your product? and how long it will take to see a return?
You cannot guess the answers to these questions and this is where you need a specialist like me to help. From my experience, it is almost impossible to get money from an investor until you have the answers to the questions above. So, how to find investors and deal with them?
What does it mean to prioritize application requirements?
Variability and inaccuracy
When you work on collecting requirements, you have a very big problem – this is detailing. As an example, one of the requirements might be to create a user registration page.
The details of this requirement will be regarding which systems we can use to authorize and register new users. Do new customers need to provide you with an email and/or phone number? Should the sign-up be verified via SMS or email? There can be a lot of variations around this which, greatly affects the flow of your product, your understanding of the customer and the budget.
Details are everything
With my first two products there was no detailing, which later became a big problem. In one situation we wanted to increase the speed of recognition of objects when the car was moving through the snow.
We discussed this requirement with the team and gave ourselves a deadline of 1-2 weeks. A week passed with no results because in the process of analyzing a lot more details we had not previously considered cropped up. What type of snow? what kind of lighting? what was along the edges of the road? what speed was the snow falling at? what was the speed of the car? did the snow stay on the windshield?
The latter question proving to be one of the most difficult queries. If we had detailed all these questions earlier we would have realized that our budget was not big enough to complete this product.
Once you have a deep understanding of the details of your product, you then need to work on prioritization and organizing your timeline. If you do not spend time on these things in advance, halfway through the development process you will suddenly realize you have run out of either time or money or maybe even both!
My mistake was that I prioritized tasks based solely on my budget. Despite there being little written about it I believe prioritization should be done by all interested parties including customers, stakeholders as well as the team.
How do you collect software requirements?
A lot of time has passed since I created my first product and I have since gained a lot of experience and knowledge.
As we speak I am currently collecting requirements for both internal products and for those of my clients. When we work with people we always explain to them why it is so important to collect all the necessary product details and requirements before anything else.
After collecting all necessary requirements we can then communicate with our customers on how realistic their expectations are with regards to budgeting and timescales. With that information, we can then prioritize the most useful areas to work on.
Remember it is important to liaise with stakeholders and explain to them your process of working however, their word should not be definitive.