5 Questions to Ask About Software Requirements Gathering

In 2011, Marc Andreessen said that “software is eating the world.” Today, this is more truer that ever. Technology has become an essential part of the our daily lives. Modern life is inconceivable without technology and in particular software that powers these technologies. Software continues to create tremendous opportunities around the world. Software can range from making the Internet function, what software application you use at work, your cell phone to Artificial Intelligence and smart devices. Software is created and maintained everyday. Software can be purchased and is also available for free. Software can be built from scratch or bought pre-built. But before software is created, before the wonderful things that software can do, we have to gather requirements about what we want the software to do.

Software requirements gathering is one of the most important aspects of creating software. It is cumbersome, manual and detailed-orientated work but it has to be done. Incorrect requirements gathering can result in software being created that no one will use or ever know how to use thus wasting a lot of time and money. In organizations, software requirements gathering is typically done by people from or affiliated with the Information Technology (IT) Department and/or external IT vendors. The level of complexity in software requirements gathering various depending if the software is being bought off-the-shelf or being custom built. In either case, there are two main issues:

IT People Are Not Domain Experts

While most IT people are ‘trained’ in gathering requirements, they are not domain experts. This means that IT people have to talk to non-IT people in the organization to understand what is needed. Depending upon who the IT people talk to, the information has to be verified by other non-IT people and any available (updated) documentation. Additionally, IT people have to translate what they have learned from non-IT people with the idea of developing a software solution. The non-IT people are the end-users of the software and thus it becomes imperative that correct and timely information is collected without any biases and preconceived notions. The IT people have to develop trust with non-IT people so that it is easier for them to be upfront about the truth.

Non-IT People Are Not Trained In Giving Requirements

While most non-IT people are willing to help in answering questions from the IT people, they are not trained in giving requirements. This means information that non-IT people share might be siloed and unintentionally incomplete because they didn’t think it was ‘useful’ or ‘relevant’. When IT people encounter this, they refer to it as “pulling teeth”. This creates tension that leads to software which is deemed ‘useless’.

The reality is that it requires both the IT teams and the non-IT teams to create software. With good open-ended contextual questions from the IT teams and with holistic thinking from the non-IT teams, any organization can create great software. To get started here are a few self-reflecting questions to ask:

Today

1. Who is going to give software requirements?
2. What has been replaced by software?
3. Where are the current roadblocks to software requirements gathering?
4. When do software requirements gathering reveals organizational weaknesses?
5. Why is software important for your organization?

Tomorrow

1. Who should be giving software requirements?
2. What should be replaced by software?
3. Where would the future roadblocks to software requirements gathering come from?
4. When should software requirements gathering reveal organizational weaknesses?
5. Why should software be important for your organization?

Originally published at http://arsalankhan.com on September 1, 2020.