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:

TodayTomorrow
Who is going to give software requirements?Who should be giving software requirements?
What has been replaced by software?What should be replaced by software?
Where are the current roadblocks to software requirements gathering?Where would the future roadblocks to software requirements gathering come from?
When do software requirements gathering reveals organizational weaknesses?When should software requirements gathering reveal organizational weaknesses?
Why is software important for your organization?Why should software be important for your organization?
5 Questions to Ask About Software Requirements Gathering

To the Cloud or Not to the Cloud

It seems like these days most organizations are interested in jumping onto the Cloud Computing bandwagon in one way or another. While there are many reasons why organizations want to move to the Cloud, I believe that optimization of business and technology processes should strongly be considered Pre-Cloud adoption. Additionally, organizations need to develop strong Key Performance Indicators (KPIs) and Service Level Agreements (SLAs) to measure against the performance of a Cloud vendor and take into consideration the consequences if the KPIs and SLAs are not met. Thus, the thought of improving your organization and inspiration from William Shakespeare’s Hamlet led me to write the following:

To the Cloud or not to the Cloud, that is the question:
Whether ‘tis nobler in the mind to suffer at the hands of IT
The processes and systems of extreme complexity
Or to take the decision to outsource against a sea of issues
And by opposing end them: to completely, to partially
No more; and by partially, to say we end
The headache, and the thousand business challenges
That implementation is heir to? ‘tis a consummation
Devoutly to be wished. To completely to partially,
To partially, perchance to dream; aye, there’s the rub,
For completely what new issues may arise
When the organization has shuffled off this essential support,
Must give us pause. There’s the respect
That makes calamity of a vendor’s contract;
For who would bear the disruptions and problems of time,
Is the management wrong, the proud man’s contumely,
The pangs of despised mind, the compliance delay,
The insolence of office and the rejection
That patient merit of the unworthy takes,
When he himself might his demise make
With outdated processes? Who would governance bear,
To complain and sweat under sub-standard operations,
But that the dread of something after completely,
The undiscovered lessons learned, from whose goal
No professional return, puzzles the will,
And makes us rather bear those problems we have,
Than ask to other that we know not of.
The conscience does make ignorant of us all,
And thus the native hue of resolution
Is sicklied o’er, with the pale cast of thought,
And enterprises of great pitch and moment,
With this regard their thoughts turn awry,
And lose the name of action. Soft you now,
The fair (insert company name here), in thy orisons
Be all my decisions remembered.

Cloud Adoption
Cloud Adoption

 

References:

  1. 5 Factors for Business Transformation
  2. 5 Questions to Ask About Your Business Processes